쿠버네티스 OOM 에러 Heap Dump 확인
장애내용 및 대응
유저가 검색한 키워드 정보를 적재하기 윈한 서비스의 카프카 리스너 파드가 계속해서 죽는 문제가 발생했다. 운영 중인 시스템의 카프카 리스너에서는 일정 갯수의 Thread가 대기상태로 유지되어 있고 메세지가 유입되면 비지니스 로직을 처리하고 대기상태로 돌아가는 구조이다. 리스너 소스에서 메모리에 영향을 줄 만한 부분이 쓰레드 부분처리하는 부분과 카프카 리스너 옵션이 영향이 있을 거라 생각해서 관련된 부분의 소스를 수정/배포 후 모니터링을 했다.
하지만 일정 시간이 지나고 계속해서 OOM 에러가 발생했다. 그래서 Java Heap Dump를 떠서 확인해 보았다.
Java Heap Dump 생성
파드 안으로 접속
$ kubectl exec -ti keyword-75b745b9f5-b78mn bash
jps 명령어로 PID 확인
$ jps
13776 Jps
17 Boot
55 keyword-0.0.1.jar
Heap Dump 생성
$ jmap -dump:live,format=b,file=keywordDump.hprof 55
$ ls
keywordDump.hprof
Thread Dump 생성
$ jstack 55 > threadDump.tdump
$ ls
threadDump.tdump
파드 안의 Heap Dump를 파드 외부로 복사
kubectl cp {namespace명}/{pod명}:{파드 외부 절대 경로} {파드내 절대 경로}
$ kubectl cp kkh-namespace/keyword-87f5b4c59-6m8fh:/kkh/keywordDump.hprof /pod/kkh/keyword.hprof
java Heap Dump 확인
Memory Analyzer 툴 다운로드 - Memory Analyzer 다운로드 페이지
Memory Analyzer 확인
Heap Dump 확인 결과 리스너에서 메세지가 유입이 되면 LinkedList 객체에 적재가 되고 LinkedList 적재된 메세지를 쓰레드가 처리를 하게 되는데 LinkedList로 유입되는 메세지가 쓰레드로 처리되는 메세지보다 많아서 LinkedList의 메모리 사용율이 올라가게 되었고 OOM 에러가 발생했던 것이다. 지금 정리는 이슈를 어떻게 처리했는지가 아닌 OOM 에러가 발생했을 때 Heap Dump를 활용해 이슈 대응을 했던 경험을 정리해 보려고 한다. 이슈 대응은 LinkedList 적재되는 최대 상한선을 두었고 Thread 처리속도를 개선해서 해당 이슈를 해결한 상태이다. 앞으로 모니터링을 진행하면서 운영중인 카프카 리스너의 최적화를 해나가야 할 것 같다.
java Thread Dump 확인
Thread Dump의 경우 Web에서 분석해주는 사이트를 찾을 수 있었고 아래 URL에 접속해서 Dump파일을 업로드 하면 분석결과를 웹페이지에서 확인이 가능하다.
https://fastthread.io/