내 애플리케이션은 JBOSS EAP 6.1에 설치되어 있습니다. 며칠 전에 우리는 애플리케이션이 느리거나 최종 사용자가 액세스할 수 없다는 사실을 발견했습니다.
우리는 기록했고 ps -aux출력 중 하나는 다음과 같습니다.
[Mon Jun 12 08:55:29.218 2017] 500 46257 90.7 10.2 22713508 6779044 ? Sl Apr26 61791:48 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.45.x86_64/jre/bin/java -D[Standalone] -server -XX:+UseCompressedOops -Xms2048m -Xmx4096m -XX:MaxPermSize=512m -Djava
이 Java 프로세스가 내 CPU를 점유하고 있는 것 같습니다. 그리고 그것은 Sl 모드에 있습니다. 이것이 나의 가정이다.
이것이 응용프로그램 문제의 원인일 수 있습니까?
CPU 사용량이 높은 이유는 무엇일까요?
JBOSS 애플리케이션 서버에서 이 프로세스의 역할은 무엇입니까?
스레드 덤프와 Gc 로그를 얻지 못했고(나중에 gc 로그가 활성화되지 않았는지 확인했습니다) 서버를 다시 시작했습니다. 지금은 로그가 없습니다.
답변1
표시되는 출력에는 서버로 실행되는 javavm 이외의 애플리케이션이 표시되지 않습니다.
사용된 메모리가 한계에 가까울 때 Java 애플리케이션에서 높은 CPU 로드가 자주 발생합니다. 가비지 수집은 메모리를 다시 확보하기 위해 계속 실행됩니다. 이로 인해 애플리케이션 성능이 저하되고 거의 모든 CPU 주기가 소모됩니다.
프로세스를 종료했기 때문에 프로세스를 알아낼 기회가 사라졌습니다.
미래에 대한 나의 제안은 JVM을 모니터링하는 방법을 구성하는 것입니다.
- GCLog를 추가하는 것은 쉬운 방법입니다.
- JMX 원격 모니터링 추가(인증을 추가하세요!) 다음을 참조하세요. http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html
- 타사 프록시가 Java 가상 머신에 직접 연결되도록 허용합니다.
이 상황이 다시 발생하면 다음을 수행할 수 있습니다.
Java 인스턴스에 대한 Java 스택 추적을 가져옵니다. (
PID 46257로 실행되는 Java)
jstack -l 46257 >jstack-output.log
그런 다음 추가 분석을 위해 힙 덤프를 수행합니다.
jmap -dump:live,format=b,file=jmap-heapdump.hprof 46257
hprof-heapdump 분석은 다양한 도구(google: java heapdump detector)를 통해 수행할 수 있습니다. 이는 높은 CPU 부하의 원인을 더 잘 찾는 데 도움이 될 수 있습니다.