oom killer 가 나타났을 때 어떻게 하세요?
글쓴이: hyper9 / 작성시간: 수, 2009/06/24 - 6:27오전
제가 사용하고 있는 System에서 oom killer가 동작하면서
System이 사용불가능한 상태가 되는 것을 경험하고 있습니다.
stack trace같은 정보를 계속 보여주면서 System은 사실 거의
정지된 것 같아보이는데요.
이럴 때는 어떤 방법으로 debugging하시는지 궁금해서요.
이런 oom killer 문제는 User level의 문제일까요?
아니면 Kernel 쪽의 문제일까요?
아니면 양쪽다 가능성이 있는 것일까요?
조언 부탁 드립니다.
그리고 혹시 Core file(?)을 이용한 debugging이 가능할까요?
어디선가 들었는데 core file을 이용하면 정확히 문제가 일어난 곳을
알려준다고 해서요..
그런데 이 core file이라는 것이 어떤 걸 의미하는지를 잘 몰라서 질문 드립니다.
core file이 생성되는 위치나 정확한 이름을 알려주신 다면 감사하겠습니다.
그리고 이 core file은 위에서 질문드렸던 것처럼 문제가 user level이거나
Kernel level이거나 모두 원인을 알려줄 수 있는 정보일까요?
모르는 것이 많습니다.
어떤 조언이라도 환영합니다. 조언 부탁드릴게요.
그럼 미리 감사드립니다..~ ^^
Forums:
서비스 장비들에서는
서비스 장비들에서는 OOM이 최대한 안나게 하고 스왑이 없는 상태로 서비스 하는데요. 가끔 OOM 나오면 뭐 리붓되어 있을때도 있고 그러던데;;;;;
여튼 core file을 생성하려면 ulimit -c unlimited 라고 해주시면 그 때부터 문제가 생겨서 프로세스가 죽으면 core[.xxxxx] 파일이 생성됩니다.
파일 생성 위치는 현재 경로이거나 프로세스가 내부에서 chdir 나 chroot를 했다면 그 위치에 생성됩니다.
보통 사용하고 있는 메모리 공간 만큼의 파일이 생겨납니다.
$ gdb 문제의실행화일 core파일
이렇게 하면 gdb가 마지막에 core파일이 생성되는 상황으로 시작하게 되고 그 때부터 bt, list 등으로 문제 시점을 trace 할 수 있습니다.
bt, list 등을 했을 때 소스코드까지 나오지 않으면 컴파일 한 소스가 있는 곳에서 시작하시고 컴파일 시 플래그에 -g 를 추가하면 디버그가 가능한 상태로 컴파일이 됩니다.
gdb 에서 break point 나 bt 시 list 라고 하면 소스코드가 나오니까 디버그 하기 무척 편합니다.
메모리를 많이 쓰는 작업이라면 실행위치의 디스크를 메모리 사용량보다 많이 남겨두세요.
http://tinyurl.com/lzmprl
http://tinyurl.com/lzmprl
http://network.hanb.co.kr/view.php?bi_id=1313
http://star4u.org
http://mirror.star4u.org
oom-killer는 signal_9 로 종료하지
oom-killer는 signal_9 로 종료하지 않나요?
signal 9은 core파일을 생성하지 않습니다.
참고하세요
댓글 달기