증상:
메시지 처리량이 산발적으로 떨어지다가 정상 성능을 회복합니다.
가능한 원인:
가능한 원인: 브로커의 메모리 자원이 매우 적습니다.
대상 및 브로커 제한이 제대로 설정되어 있지 않기 때문에 브로커가 메모리 과부하를 막기 위해 점점 더 중대한 조치를 취하게 되어 메시지 백로그를 지울 때까지 브로커가 아주 느려질 수 있습니다.
문제의 원인을 확인하는 방법: 브로커 로그에서 부족한 메모리 상태에 대한 항목 및
[B1089]: In low memory condition, broker is attempting to free up resources
새 메모리 상태와 사용 중인 전체 메모리 양에 대해 설명하는 항목이 있는지 확인합니다. 또한 JVM 힙에서 사용 가능한 메모리를 확인합니다.
imqcmd metrics bkr -m cxn
전체 JVM 메모리의 값이 최대 JVM 메모리 값에 근접한 경우 사용 가능한 메모리가 적습니다.
문제를 해결하는 방법:
JVM을 조정합니다( Java 가상 머신 조정 참조).
시스템 스왑 공간을 늘립니다.
가능한 원인: JVM 메모리 재생 이용(가비지 컬렉션)이 발생합니다.
메모리를 확보하기 위해 메모리 재생 이용이 주기적으로 시스템을 정리합니다. 이럴 경우 모든 스레드가 차단됩니다. 확보할 메모리 양이 크고 JVM 힙 크기가 클수록 메모리 재생 이용으로 인한 지체가 길어집니다.
문제의 원인을 확인하는 방법: 컴퓨터의 CPU 사용을 모니터합니다. 메모리 재생 이용이 발생하면 CPU 사용량이 떨어집니다.
또한 다음 명령줄 옵션을 사용하여 브로커를 시작합니다.
- vmargs -verbose:gc
표준 출력에 메모리 재생 이용이 발생하는 시간이 표시됩니다.
문제를 해결하는 방법: 다중 CPU 컴퓨터에서는 메모리 재생 이용이 병렬로 발생되도록 설정합니다.
-XX:+UseParallelGC=true
가능한 원인: JVM이 성능을 높이기 위해 JIT(Just-In-Time) 컴파일러를 사용하고 있습니다.
문제의 원인을 확인하는 방법: 이 문제를 일으키는 다른 원인은 없는지 확인합니다.
문제를 해결하는 방법: 잠시 동안 시스템이 실행되도록 놓아두면 성능이 향상됩니다.