저자 : 미완성 교향곡
이상
먼저 우리가 인터페이스 HTTP 요청 제한 시간의 많은 수의 응용 프로그램이 여전히 비정상 다시 시작, 아니 문제 자체가 비정상 결정하기 위해 실행되는 응용 프로그램을 리눅스 서버 네트워크 환경을 보려면 로그인 찾기 온라인 저널 플랫폼 자바 응용 프로그램 환경을 찾아 우리의 사내에 의해 만들어 문제.
예비 질문을 찾기
명령어로 :보기 GC의 JVM 메모리 풋 프린트 및 조건 -gcutil 그러면 jstat :
그것은 메모리 사용량이 오래된 년의 너무 높은 비율 것을 발견하고, 때마다 fullGC 후 효과가 복구되지 않았습니다. 다음과 같이 이전 연도의 메모리 사용 비율 변화는 다음과 같습니다
예비 판단 요청의 많은 수의 직접적인 원인 마비는 시간 제한 및 서비스 :
fullGC 메모리 풋 프린트 증가의 각 후
메모리 사용량 신속하고 빠르게 성장
더 높은 fullGC 주파수
최종 점유율 100 % 완전히 마비 서비스에 도달
분석 처리
jmap은 -histo을 : 지침을 사용하여 라이브 *** | 더 힙 메모리에서 객체의 수와 크기를보고
많은 Log4jLogEvent이 개체의 인스턴스가, 메모리를 취할 것을 발견도 매우 크고, 예비 분석은 비동기 로그 전송 속도는 메모리에 축적 로그 객체의 결과로 유지할 수있다.
단일 전송 수로의 양을 증가 최대 지연 시간 감소 : 전송 로그 수로는 조정 매개 변수를 사용하려고
응용 프로그램이 상황을 호출 다시 시작하고 인터페이스가 정상으로 일시적으로 다시 응용 프로그램을 찾아 모니터합니다.
후속 분석
명령을 사용하여 메모리 동안 이전 단계의 분석 : jmap의 -dump : 형식 = B, 파일 = 매트의 사용 분석을 실시간으로 유도 heapDump.hprof 메모리 정보 (일시적인 문제는 이후의 분석에서 처리 된하도록 덤프 프로세스가 비교적 느린) 메모리 구조 :
당신은 정말 수로 비동기 전송 로그 잼 문제입니다 목적물의 주된 정보는 힙 메모리를 차지 볼 수 있습니다.
개요
JVM의 메모리 누수 문제를 찾는 등 잘 사용 유사한 그러면 jstat의 JVM이 제공 주로에 문제, jmap는 다른 분석 도구를 해결합니다. 하지만이 문제를 해결하지만, 이러한 문제의 후속 재발의 위험은 여전히 존재한다. 그래서 JVM 문제 해결 능력을 강화뿐만 아니라, 우리는 또한 문제의 조기 발견을 용이하게하기 위해, JVM 메모리, 스레드 및 기타 실시간 성능 지표를 모니터링 할 것을 희망하는 의제에 응용 프로그램 모니터링 플랫폼을 구축 할 계획이다.
요 기사, 지원에 대한 감사를 기억 찬양의 점처럼, 모든 사용자와 공유에 오신 것을 환영합니다!