Early OOM

최근에 원격으로 여러 개의 컴퓨터를 관리하고 사용하다가 하드웨어적인 문제가 없는데도 불구하고 시스템이 뻗어버리는 경우가 몇 번 있었다.

Linux가 과연 이렇게 거지같은 시스템인 것일까 하고 막상 시스템을 확인해보면 하드웨어 적인 기능들은 겉으로 보기에 정상적으로 돌고 있는데, 오직 외부에서 신호를 보내도 전혀 응답하지 않는다는 특징을 보였다. 문제가 있는 시스템같으면 ethernet 반응을 하지 않는다든가 시스템의 LED 어딘가가 나가 있다거나 의심을 할 수 있는데, 전혀 그런 것이 없는 것이다.

결국 재부팅시켜서 로그를 보면 OOM 때문에 몇 가지 중요한 daemon이 죽어나가면서 이 사단이 발생했다는 것을 알 수 있다. 그러니까 시스템은 외부로부터 아무런 응답을 하지 않게 된 그 지경에 이르러서도 어떻게든 잘 돌게 해보려고 애를 쓰고 있었단 것이다. 문제의 사용자 프로그램이 미친 듯이 메모리를 사용하고 있는 동안에도 말이다.

Linux kernel을 공부하면 OOM이란 섹션이 있는데, 이 OOM-kill은 정말 시스템이 피치못한 경우에 process를 강제로 종료하는 것이라 시스템이 이 지경에 이르게 되면 그냥 뻗어버리는 거나 별 차이 없는 지경이라 원격관리를 하는 입장에서는 ‘OOM으로 나 재부팅했소’ 메일을 보내고 그냥 차라리 재부팅해버렸으면 좋겠지만, 그게 아니라 그냥 사실상 뇌만 살아있는 지경으로 빠져버리는 것이라 별로 좋을 게 없다. 만일 메모리를 미친 듯이 써대던 사용자 프로세스가 정상적으로 종료했다고 해도 이미 oom killer가 죽여버린 서비스들이 다시 살아나게 되지 않기 때문에 그냥 뇌만 살아있는 그 상태로 계속 머물게 되는 것이다.

Early OOM은 이걸 막아주는 요긴한 데몬이다. 주기적으로 메모리를 체크해서 한계 상황에 이르면 (oom score) 가장 memory를 많이 점유하는 process를 죽어벼린다. 딱 내가 원하는 그런 서비스다. regex로 일련의 서비스들은 이런 한계 상황에서도 죽이지 않게끔 할 수도 있다. early oom이 뭔가를 죽이면 그걸 자세히 좀 알려줬으면 좋겠는데 그렇게는 하지 않는지 로그에는 보이지 않는다.

이게 더 좋은 것은 daemon으로 떠 있어서 비정상적으로 메모리를 사용하며 폭주하는 아이들이 계속 계속 실행되어도 그 때 그 때 계속 잡아준다는 것이다. 아쉽지만 뭘 죽였는지 로그에 자세히 알려주진 않는 듯 하다. OOM의 지경에 빠지면 kernel이 어떤 process가 문제가 되는지 잘 알려주는 것과는 좀 다른 상황이지 싶다.