- 두번째로 jstat 명령을 수행 합니다.
jstat -gcutil -h20 -t 7251 3000 3000
-> gcutil : gcutil 에 대해서 수행
-> -h20 : 20라인마다 header 찍음
-> -t : time stamp 프린트(JVM 이 스타트 된 이후의 시간)
-> 7251 : 프로세스 id
-> 3000 : interval (ms 단위)
- S0 : Survivor 영역 0 의 사용율 (현재의 용량에 대한 퍼센티지)
- S1 : Survivor 영역 1 의 사용율 (현재의 용량에 대한 퍼센티지)
- E : Eden 영역의 사용율 (현재의 용량에 대한 퍼센티지)
- O : Old 영역의 사용율 (현재의 용량에 대한 퍼센티지)
- P : Permanent 영역의 사용율 (현재의 용량에 대한 퍼센티지)
- YGC : Young 세대의 GC 이벤트수
- YGCT : Young 세대의 가베지 콜렉션 시간
- FGC : 풀 GC 이벤트수
- FGCT : 풀 가베지 콜렉션 시간
- GCT : 가베지 콜렉션총시간>jstat -gcutil 21891 250 7
S0 S1 E O P YGC YGCT FGC FGCT GCT
12.44 0.00 27.20 9.49 96.70 78 0.176 5 0.495 0.672
12.44 0.00 62.16 9.49 96.70 78 0.176 5 0.495 0.672
12.44 0.00 83.97 9.49 96.70 78 0.176 5 0.495 0.672
0.00 7.74 0.00 9.51 96.70 79 0.177 5 0.495 0.673
0.00 7.74 23.37 9.51 96.70 79 0.177 5 0.495 0.673
0.00 7.74 43.82 9.51 96.70 79 0.177 5 0.495 0.673
0.00 7.74 58.11 9.51 96.71 79 0.177 5 0.495 0.673
이 예의 출력은, Young 세대의 콜렉션이 3 번째와 4 번째의 샘플간에 행해진 것을 나타내고 있습니다.
콜렉션에는 0.001 초 걸리고 있어 오브젝트가 Eden 영역 (E)으로부터 Old 영역 (O)에 승격했기 때문에,
Old 영역의 사용율은 9.49% 에서 9.51% 에 증가하고 있습니다.
Survivor 영역은, 콜렉션전은 12.44% 가 사용되고 있었습니다만, 콜렉션 후는 7.74% 밖에 사용되고 있지 않습니다.
실시간으로 메모리 사용을 좀 확인해야 하는 상황에서는 위와 같이 jstat 로 간단하게 모니터링을 수행하면
현재의 JVM 메모리 사용 상황을 확인이 가능할 것 같습니다.
가장 정확한 건 GC 로그를 별도의 파일로 출력하게 해서 분석하는 것이지만, 이럴 경우에는 실시간으로 확인이 힘들기 때문에
위와 같이 사용하는 것도 괜찮은 방법 중의 하나일 것 같습니다.
물론 JVM 에 계속 request 를 보내기 때문에 부하가 있을 듯 하지만, 지금 생각으로는 크게 영향은 미치지 않을 듯 하네요..
영향이 고려되면 interval을 좀 조정하든지 하면 될 듯 합니다.
[출처] Jstat 으로 JVM heap memory 모니터링 하기|작성자 솔바게
