2016-10-10 4 views
3

나는이 문제로 오래 동안 싸워 왔으며, 문제가 무엇인지 알아낼 수 없습니다. 사용 된 jdbc 연결이 유출 된 것처럼 보입니다. 이유가 무엇인지 알 수 없습니다.

  • MongoDB를
    • 웹 기반의 자바 8 응용 프로그램
    • GWT
    • 최대 절전 모드 4.3.11
    • MySQL은 : 나 우리가 사용하는 스택을위한 단계를 설정하자 Tomcat 8 (예 : C3PO 대신 Tomcat 연결 풀링 포함)
    • 최대 절전 모드 검색/Lucene
    • 는 테라코타와 EHCache는
    • 아침 이른 시간에

    문제는 일의 각 한 쌍 (때로는 모든 둘째 날은 가끔 한 번 매 10 일, 그것은 다름)이다, 우리의 응용 프로그램은 "잠급니다". 명확히하기 위해 충돌하지 않으며, 로그인하거나 아무 것도 할 수 없습니다. 모든 백그라운드 작업 - 모든 것이 중지됩니다. 이 상태에있을 때 로그인을 시도하면 로그 파일에서 올바른 사용자로 인증되었음을 알 수 있지만 응답이 전송되지 않으므로 응용 프로그램이 "회전"합니다.

    이러한 "잠금 장치"가 발생할 때와 관련된 유일한 패턴은 아침 예약 작업 또는 SAP 가져 오기가 실행될 때 발생한다는 것입니다. 항상 동일한 프로세스가 실행되는 것은 아니지만 때로는 SAP 수입 중 하나에서 잠금이 발생하거나 때로는 내부 예약 된 작업 실행 중에 발생합니다. 이러한 것들이 공통적으로 갖는 것은 업무 시간 (오전 1 시부 터 오전 6시 사이)을 벗어나 실행되며 상당히 집중적 인 프로세스입니다.

    우리는 모니터링을 위해 JavaMelody를 사용하고 있으며 매번 볼 수있는 것은이 1 - 6am 창에서 서로 다른 시간부터 시작하여 사용 된 jdbc 연결 수 (첨부 된 이미지에 따라)가 시작되는 것입니다. 일단 시작되면 잠금 장치가 발생하기 전에 시간 문제 일 뿐이며 해결 방법은 Tomcat을 바운스하여 응용 프로그램을 다시 시작하는 것입니다.

    lock up이 발생할 때 메모리, CPU 등등 모두 괜찮습니다. 문제가있는 것처럼 보이는 것은 사용 된 jdbc 연결 수가 지속적으로 증가한다는 것입니다.

    나는 트랜잭션이 올바르게 닫혀 있는지 확인하기 위해 트랜잭션 관리 코드를 여러 번 확인했다. (트랜잭션 관리 코드는 try old에서 명시 적으로 시작하고 커밋하고 catch 블록과 엔티티 관리자에서 롤백한다. finally 블록에서 닫는다). 그것은 모두 나에게 맞는 것처럼 보입니다. 그래서 저는 정말로, 정말 곤란합니다. 이 외에도 최근에 명시 적으로 절전 모드 연결 해제 모드를 after_transaction에 명시 적으로 구성했지만 여전히 문제가 발생합니다.

    다른 이상한 점은 다른 클라이언트에 대해 동일한 응용 프로그램의 여러 인스턴스를 실행한다는 것입니다.이 문제는 한 클라이언트에서만 정기적으로 발생합니다. 그들은 우리의 고객이며 처리해야 할 데이터가 훨씬 많습니다. 모든 클라이언트가 이러한 예약 된 작업을 실행하지만이 큰 클라이언트는 SAP 가져 오기가있는 유일한 클라이언트입니다. 이것이 내가 원래 SAP 수입이 문제라고 생각한 이유이지만, 오늘 아침 1시 이후로 잠겼으며 수입이 시작되기도 전에 몇 시간이 걸렸습니다. 이 경우 내부 예약 된 작업 실행 중에 잠겼습니다.

    이 이상한 행동을 일으킬 수있는 사람이 누구인지 알고 있습니까?나는 내가 생각할 수있는 모든 것을 보았지만 아무 소용이 없었다.

    coladict가 말했듯이

    enter image description here

  • +0

    거래가 종료 중이지만 엔티티 관리자를 종료한다고합니까? 연결을 다시 풀에 풀기 위해 닫아야합니다. – coladict

    +0

    @coladict 언급 한 바와 같이, 나는 커넥션 릴리즈 모드를 트랜잭션 이후로 설정하여 문서에서 이해할 수있는 한 커밋/롤백시이를 해제해야하기 때문에 사실이라고 생각하지 않습니다. 어쨌든, 내가 궁금한 점은 마침내 블록에서 엔티티 관리자를 닫는다 고 말한 이후의 논점이다. – brent777

    +1

    누출을 찾는 데 도움이되는 모니터링 페이지의 "시스템 정보"섹션에 "열린 jdbc 연결"링크가 있습니다. 열려있는 연결이 있다면 연결이 생성 된 곳의 스택 추적을 얻을 수 있습니다. 그 피크는 Hibernate의 어딘가에있을 것입니다. 그러나 클래스에 도달 할 때까지 내려야합니다. – coladict

    답변

    0

    많은 시간과 많은 시행 착오 끝에 팀과 저는이 문제를 해결할 수있었습니다. JDBC 커넥션의 스파이크가 락업의 원인이 아니라 락업의 결과라고 밝혀졌습니다. 아파치 테라코타가 범인이었다. 보이는 것처럼 반응이 없어졌습니다. 리소스 할당 문제 일 수도 있지만 사용률이 낮은 서버에서 발생했기 때문에 그렇게 생각하지 않습니다. 충분한 리소스를 사용할 수있을만큼 충분한 리소스가있었습니다.

    운 좋게도 우리는 실제로 더 이상 테라코타가 필요하지 않으므로 제거했습니다. 제가 말씀 드렸듯이 우리는 매주 최소한 일주일에 한 번씩 이러한 묶음을 며칠마다 보내고있었습니다. 그것을 제거한 이래로 우리는 4 개월 동안 그런 유치장을 세우지 않았고 세고 있습니다. 그래서 누군가 다른 사람이 같은 문제를 경험하고 테라코타를 사용하고 있다면 그것을 떨어 뜨리십시오. 그리고 제 경우와 마찬가지로 일이 올 것입니다.

    -1

    , 당신은 javamelody 모니터링 보고서에서 "오픈 JDBC 연결"페이지를 볼 필요가 서버 전에 "잠급니다".

    죄송합니다. 아침 2시 또는 3시에해야하지만, 밤에는 자동으로 wget 명령을 실행할 수 있습니다.