아침은 다음과 같이 문자 메시지, 특정 알람 메시지가 나타납니다
[UMP JVM 메모리 경보 모니터링 애플리케이션 이름] 티켓 발행 작업자 (jdos_couponwkr) KEY] 힙 메모리 [coupon.send.worker.jvm, 호스트 호스트 10-183-72-114 [] [11,909,223,645 예로 이용 3 회 설정된 임계 값 [90.0 %]를 초과한다. 경보 수준 : [경고], 알람 시간 : [2019년 7월 17일 7시 36분 12초].
그는 기계 힙 메모리 사용량이 90 %의 임계 값을 초과가 있다고 말했다. 하지만 기술적 인 세부 사항 뒤에 숨겨진 메시지 간결하지만, 나는 현혹, 알려 주시기 바랍니다 무엇 상태로 여기입니다.
언뜻이 알람에서 다음 힙 메모리 사용량이 임계 값을 초과 알고있다. 첫 번째 반응은 라인 큰 스택 메모리 전송 이내이다. 그러나이 정말 사실? 이제 살펴 보자.
우리는 다음과 같이 힙 메모리는 1G, 힙 메모리 사용량 곡선에있다 가정하자 :
당신은 매우 부드럽고, 정상 재활용, 전체 정상적인 사용을 볼 수 있습니다.
다음과 같이 이제, 우리는 힙 메모리 사용량 곡선 내에서 2G로 조정 메모리 내 힙을 가지고 :
그것은 여전히 힙 메모리 크기에 간단한 조정을 나타내는, 90 %를 초과하는 힙 메모리 사용량에서 볼 수있는, 당신은이 문제를 해결할 수 없습니다.
이유는 무엇입니까? 힙 메모리의 사용에 JVM 작업이 적응되면 더 제공하기 때문에, 훨씬 덜 줄이 덜 사용합니다. 당신이 그것을 1G 크기를 줄 이유 그래서이, 그것은 사용되는 메모리 힙의 90 % 이상이 될 것입니다, 당신은 그에게 2G 크기를주고, 그가 사용되는 메모리의 90 % 이상을 적재 할 수 있습니다. 물론 전제는 많은 양의 메모리 2G에서 작업에 대한 응용 프로그램을 사용하는 것입니다. 그렇지 않으면 2G 힙 메모리에 할당 너무 높은 사용되지 않습니다. 1.5G 정도는 릴리스에서 사용할 수 있습니다.
가비지 수집 메커니즘에 대한 이야기를 가자. 여기 알고리즘에 대한 기존의 알고리즘 외부 집합 G1. 의 비교하자 :
다음과 같이 힙 메모리 도커 8G, 동일한 애플리케이션은 동일한 동작으로, 압력 테스트 결과는 :
1. 젊은 GC 시간, 20 시간 이전 알고리즘, G1 알고리즘 8 배.
2. 최대 힙 메모리 사용량은, 기존의 알고리즘은 최대 6.3G는, G1 알고리즘은 최대 7.6G를 사용하여 사용합니다.
알 수있는 바와 같이, 힙 메모리 8G 장면, 우수한 전반적인 성능 알고리즘 G1에 적은 시간, 힙 메모리를보다 효율적으로 활용 GC.
그러나 다음과 같은 경우에 사용되는 8 세대 힙 메모리는, G1 알고리즘 장점은 명확하지 않다. 강력하게 큰 응용 프로그램 힙 메모리가 G1 알고리즘을 열 것을 권장합니다.
마지막으로이 메시지가 메시지 내용을 점검 할 필요가 발생했다.
1. 용인 GC 시간이 소요되는 문제를 해결해야 할 1 초 이상은 40ms 이하 정상보다 평균 소비.
자주 필요가 문제를 해결하는 것으로 나타납니다 분 이내에 GC, 여러 번 또는 수십 번 전체 번호를 확인합니다.
3. 그것은 오래된 재활용 할 수 없습니다 년, 이유, 다음과 같은 그림을 식별하는 코드를 확인 의미 메모리 사용량이 올라갈 경우 그래픽, 메모리 복구 힙하지만 지연이 내려 확인 :
이 그림에서 볼 수있는, 내부 로컬 캐시의 응용 프로그램이 실행 되었기 때문에 최대 곡선은 내려하고 나중에 만료 선도, 어떤 메커니즘이 로컬 캐시가 제대로 재활용 밖으로 폐쇄하지 않습니다.
곡선의 가장 높은 지점은 현재 힙 메모리 사용량이 높은 정점 된 경우, 응용 프로그램이 많은 수의 할당 된 힙 메모리보다 더 많은 메모리를 필요로, 현재 설정에 맞춰 사용 JVM 힙 메모리 크기를 확인하려면 충분한 메모리 자원이 될 수 있습니다 일부는 힙 메모리의 경우보다 더 많은 할당하려고합니다.