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

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
,
앞서 String.intern() 메소드를 사용하면 Perm 영역에서 GC가 많이 발생할 수 있다고 했다. 
http://tuning-java.com/455 참고.
그런데, 이 글을 읽는 분들은 대부분 아시겠지만, Perm 영역에는 클래스와 메소드등의 정보가 들어가게 된다. 많은 클래스를 읽어들일 수록 Perm 영역은 당연히 부족해지고, Full GC를 발생시킬 수 있다. 

이런 문제를 발생시키는 주된 원인은 Reflection을 사용해서 메소드 호출등을 할 경우도 포함된다.

왜 Perm 영역에서 Full GC가 발생할 수 있는지에 대한 설명이 잘 되어 있는 문서다. 
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html

 관심 있는 분들은 한번 정도 읽어 보면 좋을 듯 하다. 

그리고, 
http://coding.derkeiler.com/Archive/Java/comp.lang.java.programmer/2006-11/msg00122.html
이 글도 보면 도움이 될 것이다. 
 
Posted by tuning-java
,
악성 코드가 있는 사이트를 방문했는지,
구글 크롬의 화면이 하얗게 변해버리는 일이 종종 발생했다.

구글 크롬의 임시파일을 지워도 별로 달라지는것이 없어서  캐시 디렉터리를 통채로 지우기로 마음 먹었다.
위치는
/Users/사용자아이디/Library/Caches/Google/Chrome/Default 
에 있으며 이 디렉터리를 통채로 날려버리면 된다.
 
rm -rf *

이렇게 지우고 나니 깔끔하게 모든 페이지가 작동중...
 
Posted by tuning-java
,
내가 지금까지 본 글 중에서 가장 마음에 쏙 들게 작성되어 있다.
(물론 시간 관계상 그림만 봤다. ㅎㅎ)

http://www.ibm.com/developerworks/java/library/j-codetoheap/index.html 
Posted by tuning-java
,