WAS에서 지속적인 Heap Memory 누수현상이 있었나요?
제니퍼 2.5에서 처음 선보인 “지속적인 Heap Memory Leak”을 잡아가는 콜렉션 추적 과정은 다음과
같습니다.
1. [통계분석]->[메모리] 메뉴로 가셔서 지난 며칠동안의 Heap Memory의 경과를 먼저 확인합니다.
만약, 시간이 지남에 따라 “일일자바힙(Heap) 메모리 사용량”의 그래프가 증가하고 있는지
확인하는 것이지요.
2. [장애진단]->[메모리-콜렉션]메뉴로 이동합니다.
위에서 보면 어떤 콜렉션(Vector/Hashtable/etc..)객체가 얼마만큼의 element를 갖고 있는지 보입니다.
보다 구체적으로 어떤 어플리케이션에서 위 컬렉션에 Add했는지를 보려면, [accept]버튼을 눌러줍니다.
그러면 다음 그림과 같이 상태가 waiting…으로 바뀝니다.
이제 만약, 어떤 어플리케이션에서 위 객체에 새로운 element를 추가하려고 시도할 때, 그 stacktrace를
떠서 담아 주게 되므로, F5키나 Enter를 주기적으로 눌려 상태가 “waiting…”에서 “included”로 바뀔
때 까지 기다립니다.
위와 같이 STACK이 “included”상태로 되었을 때, 마우스를 그 콜렉션(위에선 java.util.HashMap)위로
가져가면 다음과 같이 어떤 어플리케이션에서, 어떤 객체를 위 콜렉션에 추가했는지 확인됩니다.
위에서 보면 session.jsp가 Tomcat의 HTTP Session에데가 StandardSession이라는 객체를 넣었고, 현재
14,580개의 element가 담겨 있음이 확인됩니다.
그러나, 단순히 element 개수가 많다고 하여 메모리를 많이 사용했다고는 장담할 수 없습니다. (조만간
element의 Byte크기를 보여줄 줄 수 있도록 하겠습니다.) 그렇기 때문에 지속적으로 증가하는 것이
Heap Memory의 증가와 상관관계가 있는가를 판단할 필요가 있습니다.
메뉴에서 [snapshot]을 누르면, DELTA항목이 0로 바뀝니다. (TOTAL은 element개수로서, 초기화할 수 없는
값입니다.) DELTA항목은 [snaphot]을 누르면 0으로 초기화 되고, 그 다음부터 element가 늘어난 개수를
보여주게 됩니다.
이처럼 TOTAL 및 DELTA값의 변화가 Heap Memory의 증가와 관련이 있는지 직관적인 판단이 되면, 앞서 구한
Stacktrace 혹은 몇차례에 걸쳐 StackTrace를 떠서, 동일한 어플리케이션에서 발생되고 있다면, 이를 갖고
개발자와 어플리케이션 소스를 Reivew하는 단계로 진입하면 될 것입니다.
이처럼 제니퍼2.5의 메모리/콜렉션 추적은 지속적인 Heap Memory Leak의 원인을 잡는데는 매우
효과적이었다는 것이 여러 사이트에서 확인되었습니다. 모든 LiveObject개수 추적은 [장애진단]->
[라이브오브젝트] 메뉴에서 확인가능합니다. 그러나, 어떤 객체가 메모리를 얼마나 사용하고 있느냐
보다는 누가 그 객체를 생성하여 밀어넣었냐는 것을 찾는 것이 더욱 중요한 부분입니다.
또한, 몇백MB의 메모리를 점유할 수 있는 구조는 그래봐야 Hashtable, Vector, HashMap과 같은
콜렉션(Collection) 객체 일 수 밖에 없다는 것이죠.
NOTE:
[snapshot] : DELTA 값을 모두 0으로 초기화하여 그 다음 element가 들어올 때부터 증가시킵니다.
[stackclear] : 현재 켑쳐한 모든 stacktrace를 지웁니다.
[accept now stack] : 리스팅 된 모든 콜렉션의 상태를 향후 stacktrace를 받아들이기 위해 waiting상태로
만듭니다.
각 콜랙션 개별적으로 위와 같은 작업을 하려면 각 개별 콜랙션에서 [accept][clear][accept new] 메뉴를
활용하면 됩니다.
collection_minimum_monitoring_size = 1000 : JVM 내부엔 많은 콜렉션이 있을 것입니다. 이 수치를 넘어서는
것에 한해서만 리스팅 됩니다. 실시간 적용되나, WAS를 재시작
하면 다시 초기값으로 바뀝니다. 영구설정은 [구성관리]->
[구성설정]에서 각 WAS별로 지정해 주면 됩니다.
collection_auto_stacktrace_size = 10000 : 비록 리스트에 나나났다해도 명시적으로 [accept]를 눌러 STACK을
받아들일 준비가 되어 있지 않으면 STACK이 쌓이지 않습니다.
그러나, 이 element 개수가 이 수치를 넘어서면 자동으로
STACK이 쌓입니다. 참고로 실사이트에 보면 10만개를 넘어서면
이슈화가 되곤 하더군요.
NOTE: 메모리-콜렉션 추적에 따른 성능저하도는 상대적으로 매우 미미합니다.
NOTE: IBM JDK를 사용하고 있을 경우는 제니퍼와 무관하게 heapdump파일을 분석함으로써 95% 이상 거의
대부분의 원인을 판단할 수 있습니다.
자바서비스넷 이원영
Phone: 010-6239-6498
E-mail: NOSPAM_lwy@javaservice.com
MSN: NOSPAM_javaservice@hanmail.net
 memory3.gif (13198 Bytes)
memory2.gif (12821 Bytes)
memory5.gif (12791 Bytes)
memory0.gif (79329 Bytes)
memory4.gif (21654 Bytes)
memory1.gif (12891 Bytes)
|
