Heap Analyzer를 통해서 Memory leak을 분석을 위해 아래와 같이 Tree view를 확인하고 Memory를 많이 차지하거나 leak이 있을 의심스러운 곳을 마우스 오른쪽 클릭을 하여 locate a leak suspect부분을 누르면 아래와 같은 화면을 확인할 수가 있습니다.
아래 분석 결과를 보면 110M에서 8M로 급격히 떨어지는 부분을 확인 할 수가 있는데, 모두 java.util.hashtable(대략 5K)이 모여서 110M 정도의 메모리를 소요하고 있음을 확인 할 수 있습니다. 대략적으론 이렇고 어느 어플리케이션 에서 일으키는지 확인하려면 heapdump 발생 후에 발생한 javacorexxx.txt를 분석해야지 알 수가 있습니다.
아래는 dump 분석 결과를 보면 정확히 JSP 라인수는 알수가 없으나 StringBuffer관련 obj를 많이 담을 때 발생한다는 것을 알 수 가 있었습니다. 해당 라인을 어느 정도 확인 하시려면 javacore dump와 같이 분석을 하셔야 합니다.
문제의 원인은 아래 class의 replace method에 있었음을 위 heapdump 및 javacore 의 분석을 통해 알 수 있었으며 상황재현은 Optimizeit이라는 tool을 이용하여 고객에게 상황재현을 시켜 주었습니다.
JSPHelper.replace(vo.A01_PTNM,""," ")
위 에러는 로직 버그인데 Null check에 대한 exception이 정의가 안되어 있어서 StringBuffer에 append하는 과정에서 과도한 메모리를 사용하는 것으로 결론이 났습니다.
'1. 미들웨어이야기 > 01. JVM' 카테고리의 다른 글
| CPU 과부하로 인한 응답속도 저하 패턴 (0) | 2009.06.03 |
|---|---|
| OutOfMemory 문제분석 by HP Jmeter (0) | 2009.06.03 |
| OutOfMemory 문제분석 by JEUS (0) | 2009.06.03 |
| OutOfMemory 현상정리 (0) | 2009.06.03 |
| classloader 상의 해당 class 위치 찾기 (0) | 2009.06.02 |