Java 힙덤프 분석 (Out of memory현상이 아닌 수동분석)

어..? 메모리 부족..?

서버 운영 중에 간헐적으로 접속 장애가 발생했다. 우리 서버에는 scouter로 모니터링 시스템을 구축해놓았었고 이상 증상이 있으면 사내 slack에 특정 채널로 알림이 오게 해두었다.

며칠 전부터 서버의 메모리가 부족하다는 알림이 오기 시작했다. 하지만 다른 업무들이 밀려 있어서 신경쓰지 못했다.

상황 발생!! 비상!!

그런데 어제부터 특정 사이트에 접속이 간헐적으로 안된다는 문의가 들어왔다. 확인을 안할 수 없는 상황이 되었다.

우리는 아파치 웹서버를 앞에 두고 로드밸런서처럼 사용하고 있었다. 그 뒤에는 Tomcat WAS를 이중화해놓았고 이 중에 한 서버에서만 메모리가 부족해져 있었다. 물론 나머지 한 서버도 메모리가 많이 올라와있기는 마찬가지였다.

우선 tomcat을 오랫동안 켜두어서 그런것이라는 경험에서 나온 추측을 했고, 고객사와 협의를 통해서 다음날 오전에 tomcat을 리부팅하는 작업을 하기로 했다. WAS가 이중화 되어 있고 웹서버가 앞단에 따로 있기 때문에 사용자는 알 수 없게 무중단 패치가 가능했지만 혹시 모를 상황에 대비하여 고객사와 협의를 했다.

급한 불은 껐고.. 근본적인 원인은?

다음날 오전에 리부팅 작업을하니 실제로 메모리가 절반가까이 줄어들었다. 이거는 무조건 메모리 누수인 것으로 판단이 되었고 누수가 어디서 발생하고 있는지를 분석해야할 필요성을 느꼈다.

이 때문에 사내의 윗분들은 앞으로 추가될 고객사가 예정되어 있었는데 이를 대응하기 위해서 서버 추가 증설(스케일업 또는 스케일아웃)을 고민하는 치열한 토론이 있었다.. 금전적인 부분과 효율적인 부분(실제로 운영하는 실무자 관점)에서 스파크가 튀는 토론이었다.. (실무자 입장을 고려해주시는 윗분이 있다는 것에 정말 감사합니다..! 🙏)

힙덤프(heapdump) 분석해보자!

그건 그거고! 일단은 나는 문제해결을 위해서 웹서버에서 한쪽 Tomcat으로의 트래픽을 차단하고, heapdump를 생성했다. 그리고 memory analyzer Tool을 사용하여 해당 덤프파일을 분석했다.

java 사용 프로세스 아이디 확인

먼저 힙덤프 생성 명령문에서 프로세스 아이디가 파라미터로 필요하기 때문에 아래 명령어를 통해서 힙덤프를 생성할 프로세스 아이디를 확인한다.

$ jps -v

java process 라고 생각하면 외우기 쉽다!
꼭 웹 서버가 아니더라도 Java 프로그램이면 힙덤프를 할 수 있을 것이다.

힙덤프 생성

java로 실행된 프로세스의 아이디 목록 중에 힙덤프 대상인 tomcat의 프로세스 아이디를 파라미터로 넘겨서 힙덤프를 생성해보자.

주의할점
힙덤프를 생성하는 중에는 해당 프로세스가 멈춘다고 보면 된다. 따라서 서버가 이중화되어 있지 않은 상태에서 운영중인 서버에 대해 힙덤프를 생성하면 서비스가 중단될 수 있으므로 꼭 알아두자!

만약 고객사와 협의가 안된 상태에서 운영중인 서버에 대해서 간단하게라도 힙덤프를 확인하고 싶다면 아래 명령어를 통해서 확인해보자.

힙 점유율 확인을 위해 힙 히스토그램을 서버에서 직접 확인해보자.
툴을 사용하지 못하는 환경이라던지 서버 CLI 환경에서 확인해야하는 경우 유용할 것 같다.
$ jmap -histo {pid} | more

full GC를 하기 위해서는 아래 명령문으로 해보자. GC는 일어나면 알다시피 Stop The World! 가 발생하기 때문에 주의하자! (내가 해봤을 때에는 짧게 끝났고 서비스에는 거의 영향이 없었으나 각자 서버 상황이 다르기 때문에 감안해서 사용하자.)
$ jmap -histo:live {pid} | more

(여기서는 more를 파이프라인으로 넘겨서 조금씩 보게 했는데 한방에 전부 출력하고 싶으면 해당 파이프를 제거하고 앞에 명령문만 치면 됩니다~)

덤프 파일을 생성하는 방법은 아래 명령어를 입력하면 된다.

주의할점은 운영 중인 서버라면 서비스가 중단될 수 있다는 점!! 꼭 명심하기 바란다.

// pid가 1234인 자바 프로세스의 heapdump 파일을 대상 디렉토리에 생성
ubuntu@ubuntu:/home/ubuntu/heap$ jmap -dump:format=b,file=/tmp/heapdump.hprof 1234
ubuntu@ubuntu:/home/ubuntu/heap$ ll
total 8184540
drwxrwxr-x  2 ubuntu ubuntu   28 11월 10 10:54 ./
drwxr-xr-x 10 ubuntu ubuntu  284 11월 10 18:44 ../
-rw-------  1 ubuntu ubuntu 7.9G 11월 10 10:54 heapdump.hprof

7.9GB 짜리 덤프 파일 생성됨.. 용량 왜이렇게 커 .. 덤프 명령어 잘못한거 아니지..?

해당 파일을 서버에서 확인할 수 있는 명령어가 있다.

jhat 이라는 명령어인데 해당 툴로도 확인할 수 있지만.. 나 같은 경우 덤프 파일 용량 자체가 너무 크기 때문에 해당 명령어로 분석하려면 며칠이 걸릴지 모르겠다.. 그래서 파일을 로컬로 다운로드 받아서 memory analyzer라는 이클립스 비슷하게 생긴 툴로 분석해보았다.

힙덤프 분석 (Memory Analyzer 사용)

memory analyzer (이클립스 기반) 다운받고 해당 tool 사용해서 히스토그램이라던지 힙덤프 분석해보기.
http://www.eclipse.org/mat/downloads.php

Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation

The Eclipse Foundation - home to a global community, the Eclipse IDE, Jakarta EE and over 415 open source projects, including runtimes, tools and frameworks.

eclipse.dev

- 7.9GB 덤프 분석하는데 툴의 max heap memory를 4GB로 잡아도 뻗음. 8GB로 잡으니까 분석됨. (힙 메모리를 크게 잡아줘야함)
- 덤프 open이 끝나니까 leak suspect(누수 추적?) 할거냐고 popup이 뜸. 좋네! 선택하니까 leak되는부분이 pie 차트로 나옴. 확인해보니까 session이 누수 추적결과로 가장 많은 공간을 차지하고 있었고, 실제로 대민과 관리자 모두 session timeout이 무한이었음.
- OQL 이라해서 결과를 SQL문처럼 조회할 수도 있는 것 같은데 나는 안보임.. (플러그인 설치해야하나?)
- histogram으로 확인해보니 byte[] 다음으로 java.util.concurrent.ConcurrentHashMap 객체가 가장 많았음. (Hashmap을 상속해서 커스터마이징하여 사용하고 있는 객체가 가장 많이 차지하고 있는 듯함. 그 다음이 StandardSession임. 그리고 String, ArrayList, java.lang.reflect.Method 순서)