- JVM 덤프를 뜨는 이유: Java application이 먹통이 되는 등의 문제가 생겼을 때 문제가 뭐였는지를 알아내서 다음에는 안 그러도록 예방하려고.
- 좀 더 나아가 문제가 생기기 전에 미리 알아내서 예방할 수도 있다.
- JVM 분석 방법
- 평소에: APM(Application Performance Monitoring) 등으로 모니터링한다. 예를 들어 Naver Pinpoint가 있다.
- 일이 터진 후: 일이 터진 시점에 덤프를 뜬다. Thread dump와 Heap dump를 뜨고, 일단 일을 수습한 후 나중에 분석한다.
- 덤프 뜨는 법
- JDK에 jstack, jmap이 기본으로 들어있으니 이걸 쓴다.
- 먼저 ps -ef로 pid를 찾는다.
- Thread dump: jstack {pid} > thread_dump_1.tdump
- Heap dump: jmap -dump:format=b,file=heap_dump.hprof {pid}
- Thread dump는 시간 간격을 두고 한 3개 정도 떠 놓는다. 현재 사용중인 Thread가 실행하는 과정에 따라 달라지기 때문에, 문제가 되는 Thread가 dump 시점에 실행되지 않을 수도 있기 때문이다.
- 반면 Heap dump는 그렇게까지 변하지는 않기도 하고, 메모리를 사용하는 만큼 덤프가 생기니까 너무 오래 걸리기도 해서 하나만 떠 놓는다. 예를 들어 메모리를 2GB 쓰고 있으면 덤프도 2GB가 생긴다.
- 그리고 dump를 뜨는 동안 자바 앱이 완전히 멈춘다. Thread dump야 금방 끝나니까 괜찮지만, Heap dump는 용량이 커서 한 3초 정도 멈출 수 있는데, 이런 위험을 감수할 정도로 심각한 상황에서만 해야 한다.
- 덤프 보는 법
- 여러가지가 있지만 IBM 것은 아래와 같다.
- Thread dump: IBM Thread and Monitor Dump Analyzer for Java (TMDA)
- Heap dump: IBM HeapAnalyzer
- Thread dump는 현재 Thread들이 running인지, waiting인지, blocked인지가 나오니까, 이중에 이게 waiting이나 blocked일리가 없는데 그런 것들을 하나하나 찾아가다보면 의심이 가는 걸 찾을 수 있을 것이다. 무슨 클래스의 무슨 메소드의 몇번째 줄인지 나오니까, 인내심을 가지고 열심히 뒤지다보면 언젠가는 찾을 수 있을 것이다. 아까 덤프를 3개 떠놨으니까, 나올때까지 그 3개를 전부 뒤져봐야 하고, 정말 운이 없으면 그 3개 안에 없을수도 있다.
- Heap dump는 아직 Garbage Collection(GC)가 안된 것들의 메모리 사용량을 보는 것이다. 그 중에 유난히 많은 것이 있다면 그게 문제일 수 있다. 옛날에는 DB 연결하고 제대로 안 닫아줘서 memory leak이 나는 경우가 많았는데, 요즘은 Spring JPA 같은 거 쓰면 다 알아서 해주니까 딱히 문제가 있진 않다. 그보다는 100행만 읽어와야 할 것을 10만 행이나 읽어오는데, 그걸 또 DB가 아주 빠르게 줘서 딱히 blocked 되지도 않아서 그냥 메모리만 많이 쓰는 경우가 있었다. 이게 응답속도도 그렇게 느리지 않다보니 찾기가 어려웠다.
- GC는 요즘 왠만하면 G1GC 쓰는데, JDK 1.8은 이게 아직 기본값이 아니니까 명시적으로 지정해줘야 한다. 그리고 G1GC는 메모리가 많을수록 성능이 좋고, 적어도 1GB는 넘어야 성능이 나오니까 넉넉히 주는게 좋다. 그리고 옛날에는 OutOfMemory(OOM) 덜 나게 하려고 Permgen 크기를 수동으로 크게 잡기도 했는데, JDK 1.8 이상부터는 이게 없어지고 자동으로 늘어나는 다른 방식으로 바뀌었다. 그것도 Metaspace라고 설정은 할 수 있지만 웬만하면 JVM에게 메모리 관리는 알아서 하라고 믿고 맡기고, 우리는 어플리케이션에서 사람의 에러를 찾는게 낫다.
