출처 : http://cafe.naver.com/hermeneus/76
가이드 : http://wiki.eclipse.org/index.php/MemoryAnalyzer
자바 웹 개발자로서 듣기 가장 무서운 단어중에 하나는 out of memory 일 것이다.
메모리의 누수가 없도록 개발해야 하는 것이 정답이지만 실수 할 수 있는 가능성이 있는 만큼 대비 또한 중요하다고 생각한다.
시스템에서 out of memory가 발생했을 때 우리는 어떤 데이터를 가지고 어떻게 분석해야할지 고민해야 할 것이다.
out of memory에 대한 대비가 되어 있지 않으면 분석할 데이터가 존재하지 않는다.
따라서 할 수 있는 것은 시스템을 재시작하는 방법 뿐이다.
메모리는 계속 쌓여 갈 것이고 가까운 미래에 또다시 out of memory를 만날 것이다.
이러한 문제를 해결하기 위한 여러가지 분석 방법 중 하나가 out of memory가 발생할 때 힙덤프를 생성하는 것이다.
JAVA에서는 친절하게 옵션으로 제공하고 있다.
-XX:+HeapDumpOnOutOfMemoryError : out of memory가 발생시에 힙덤프를 현재 실행 디렉토리에 생성한다.
-XX:HeapDumpPath=힘덤프를 생성할 경로/힙덤프이름.hprof : 지정한 경로에 생성한다.
out of memory가 발생했다면 hprof 힙덤프 파일이라는 증거물을 자동으로 획득할 수 있다.
이제 힙덤프 파일을 어떻게 분석할까??
1. 프로그램을 실행시키고 힙덤프 파일을 찾아서 열기(Open Heap Dump)한다.
2. 선택된 힙덤프를 바로 분석하여 파이형 그래프로 문제가 얼마나 있는지 한눈에 보여준다.
3. 이제 어디에 문제가 있는지 좀 더 분석해 보자.
메모리가 어느 부분에서 많이 쓰였는지 해당 인스턴스를 찾아서 나타내 준다.
Problem Suspect 1 한 부분만 봤을 때에도 문제의 원인을 대략적으로 알아낼 수 있었다.
바로 com.sun.mail.smtp.SMTPMessage[] 부분이었다.
SMTPMessage를 사용하는 곳만 찾아보아도 이미 반정도는 해결 된 문제다.
4. 좀 더 상세하게 분석해 보자.
트리 형태로 볼 수 있도록 트리 아이콘을 클릭한다.
트리는 메모리를 가장 많이 가지고 있는 쓰레드 순으로 정렬하여 보여주고 있다.
가장 문제가 큰 쓰레드를 열어보았다.
SMTPMessage 배열은 64개의 SMTPMessage 객체를 가지고 있다.
InternetAddress 배열도 64개의 InternetAddress 객체를 가지고 있다.
SenderInfoBean 클래스도 보인다.
메일을 발송하는 부분에서 사용되는 클래스가 대부분이었다.
이 세 항목으로 볼 때 메일 발송시 64개의 마임(MIME) 또는 그 이상을 생성하여 메모리에 가지고 있다가
out of memory를 발생시킨 것이라는 결론을 내렸다.
이러한 힙덤프 분석으로 문제를 발견하고 수정하는데 많은 도움을 받을 수 있었다.
몇일, 몇주, 몇달이 지나도 out of memory가 발생했다는 문제는 지금까지 보고되지 않고 있다.
▼ 아래의 경로에서 Eclipse Memory Analyzer(MAT)에 대한 자세한 정보와 프로그램을 다운로드 받을 수 있다.
