메모리 문제를 모니터링하기 위해 GC(가비지 수집기)의 로그 파일 분석
생산 환경에서 GC 로깅을 사용하는 것이 좋습니다. GC 로깅을 사용하는 방법에 대한 자세한 내용은
ThingWorx 서버의 메모리 사용량 모니터링 단원을 참조하십시오. GC 로깅이 사용되면 서버의 모든 GC 활동이 로깅됩니다. JVM이 오랫동안 응답하지 않는 경우 PSM 또는 VisualVM과 같은 외부 도구에서 메모리 데이터를 수집하지 못할 수 있습니다. 그러나 JVM은 GC 활동을 인쇄하여 메모리 문제에 대한 원인을 쉽게 식별할 수 있습니다.
GC 로그 읽기
GCEasy.io 및 Chewiebug GC Viewer와 같은 도구를 사용하여 GC 로그를 분석할 수 있습니다. 또한 텍스트 편집기에서 GC 로그를 수동으로 분석하여 일반적인 문제를 확인할 수 있습니다.
각 메모리 정리 작업은 일반적으로 다음 예와 같이 인쇄됩니다.
1. JVM 시작 이후 시간
2. GC 유형
3. GC 이유
4. 549M에서 4M로 정리된 새로운 세대
5. 총 새로운 세대 크기
6. GC가 완료될 때까지 전체 시간
7. 할당된 힙
8. Java가 정리 중인 응용 프로그램의 전체 메모리
GC 작업에 대한 자세한 내용은 Oracle 설명서를 참조하십시오.
GC 분석 도구는 정리의 텍스트 표현을 더 쉽게 읽을 수 있는 그래프로 변환합니다.
GC 로그의 데이터를 분석하면 ThingWorx 응용 프로그램에서 메모리 문제를 나타내는 다음 시나리오를 식별할 수 있습니다.
• 매우 긴 전체 GC 작업(45초 이상) - 이는 모든 동작을 중지시키는 작업이므로 매우 바람직하지 않습니다. 예를 들어, 다음 전체 GC를 수행하는 데 46초가 걸립니다. 이 시간 동안 다른 모든 사용자 활동이 중지됩니다.
272646.952: [Full GC: 7683158K->4864182K(8482304K) 46.204661 secs]
• 루프에서 발생하는 전체 GC - 이는 빠르게 연속적으로 발생하는 전체 GC입니다.
예를 들어, 다음 네 개의 연속 가비지 수집을 해결하는 데 약 2분이 소요됩니다.
16121.092: [Full GC: 7341688K->4367406K(8482304K), 38.774491 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
• 다음 그래프에서 그래프 스파이크의 빨간색 삼각형은 전체 GC가 루프에서 발생함을 시각적으로 표시하는 것입니다.
• 메모리 누수 - 메모리에 유지되는 객체 수가 점점 늘어나 메모리를 정리할 수 없을 때 이러한 문제가 발생합니다.
다음 예에서는 가비지 컬렉터가 있어도 메모리가 지속적으로 증가합니다.
권장 사항 - 시간 경과에 따른 메모리 사용량을 모니터링하고 기록하는 PSM과 같은 자동화된 도구가 없는 경우 GC 로그 파일에서 매일 메모리 문제를 확인합니다. 메모리 문제가 있으면 JVM 스레드 덤프 또는 힙 덤프를 수집하여 장기 실행 작업을 식별합니다. 이러한 작업은 ThingWorx 응용 프로그램에서 기본 메모리 문제를 트리거할 수 있습니다.