책의 내용을 보완할까 고민하다가, 그냥 블로그에 남기는 것이 나을 것 같아 여기에 정리한다.

Core dump 라는 것이 있다. 

만약 이 core dump 라는 파일을 들어본적도 없거나, 뭔지 모르는 분들은 지금까지 행복한 개발 / 운영 생활을 했다고 봐도 된다. 

리눅스에서는 gcore라는 명령어를 사용해서 코어덤프를 남길 수 있는데, 문제가 생겼을 때 (비 정상적으로 JVM이 죽었을 때 아무런 로그가 없는 경우등)에는 이 코어 덤프가 한줄기 빛이 될 수 있다. 

JVM은 보통 그냥 죽지 않는다. hs_err_pid.log라는 파일을 남기고 죽는데 이 파일을 보면 어느 작업을 하다가 죽었는지를 확인할 수 있다. 하지만 얼마전에는 이 파일도 안남기는 문제를 만났다. 

기본적으로 대부분의 서버에서는 코어 덤프를 남기지 않도록 되어 있다. 왜냐하면, java에서 1 GB 의 메모리를 사용하면 코어 덤프는 수십 기가에 달하는 파일을 생성하기 때문이다. 

JVM이 팍~ 하고 아무런 근거를 남기지 않고 죽었으면 둘 중 하나다.

누가 kill -9 pid로 프로세스를 죽었거나, segfault와 같이 프로세스 내의 오류로 죽는 경우다. 

그 범인을 잡으려면 로그를 봐야한다.

/var/log/messages 

파일을 root 권한으로 보면 그 시점에 어떤 오류가 발생했는지를 확인할 수 있다. 


1. 코어덤프 자동으로 생성하게 만들기

먼저 core dump를 자동으로 생성토록 하려면  ulimit -a 라는 명령으로 서버 설정을 확인한다. 

$ ulimit -a

core file size          (blocks, -c) 0

이하 생략

이처럼 가장 끝에 있는 값이 0 이면 core dump 는 안남는다. 덤프를 남기도록 변경하려면

ulimit -c unlimited

명령을 실행하면 core dump가 남을 것이다. 단 디스크가 꽉 차버릴 수가 있으므로 조심해서 옵션을 변경해야만 한다.

unlimited로 변경한 콘솔 창에서 실행한 프로그램은 팍~~ 죽어버리던, 문제가 생기던 core dump 가 실행한 위치에서 남는다. 확인해 보려면 자바 프로그램 아무거나 작은거 하나 실행하고 

kill -11 pid

를 실행해 보기 바란다. 그러면 core dump가 남아야한다. 만약 제대로 안했다면 코어덤프는 남지 않는다. 


2. 코어덤프 분석하기

코어덤프 파일을 열기 위해서는 gdb라는 프로그램을 사용하면 된다. 자바 프로그램을 확인하려면 

gdb /자바실행파일FullPath/java core.pid

로 실행하면 된다. 그러면 인터프리터 방식으로 이 툴을 사용할 수 있다.

gdb라는 것을 사용한게 별로 안되기 때문에 내가 옆에서 어깨 너머로 배운 명령어는 다음과 같다.

bt
info thread
thread 쓰레드번호
where
x/i 메모리주소값

각 명령에 대한 자세한 설명은 여기서 생략한다. 직접 한번 돌려보면 알꺼다. ㅎㅎ(나도 잘...)

그런데, 코드가 완전 C로 되어 있다면 스텍 정보들이 제대로 나오겠지만, java로 되어 있으면 보기가 어렵다. (그냥 메소드 이름이 ??로 나온다.)

그럴때 사용하는게 바로 jstack이다.


3. jstack 으로 core dump의 쓰레드 덤프 생성하기

jstack으로 coredump의 쓰레드 덤프를 생성하는 방법은 다음과 같다.

jstack /자바실행파일FullPath/java core.pid

이렇게 실행하면 jstack이 코어덤프에서 쓰레드 덤프를 추출해준다. 마찬가지로 jmap 을 이용해서 core dump  에서 힙 덤프도 만들 수 있다.

이제 필요한 덤프들을 생성했으면, 

"자바 개발자와 시스템 운영자를 위한 트러블 슈팅 이야기" 책을 보면서 원인을 잡으면 된다.

ㅎㅎㅎㅎㅎ




Posted by tuning-java
,