OOM Killer는 어떤 기준으로 프로세스를 종료할까?

OOM Killer는 어떤 기준으로 프로세스를 종료할까요

리눅스 시스템을 사용하다 보면 갑자기 특정 프로그램이 예고 없이 종료되는 경험을 해보신 적이 있으실 겁니다. 특히 메모리 사용량이 많은 작업을 할 때 이런 현상이 발생하곤 하는데요. 이럴 때 시스템 뒤편에서 조용히, 하지만 단호하게 작동하는 존재가 바로 ‘OOM Killer’입니다. OOM은 ‘Out Of Memory’의 약자로, 말 그대로 시스템에 메모리가 부족할 때 발동하는 리눅스 커널의 핵심 기능입니다.

OOM Killer는 단순히 메모리를 많이 쓰는 프로세스를 무작위로 종료하는 것이 아닙니다. 시스템의 안정성을 최우선으로 고려하며, 나름의 복잡하고 정교한 기준에 따라 어떤 프로세스를 희생시킬지 결정합니다. 이 글에서는 OOM Killer가 어떤 기준으로 프로세스를 종료하는지, 그리고 우리가 이를 어떻게 이해하고 활용할 수 있는지에 대한 종합적인 가이드를 제공합니다.

OOM Killer는 왜 필요할까요

컴퓨터 시스템에서 메모리는 마치 작업 공간과 같습니다. 작업 공간이 충분해야 여러 작업을 동시에 원활하게 처리할 수 있습니다. 만약 이 작업 공간이 부족해지면 어떤 일이 벌어질까요? 시스템은 극도로 느려지거나, 아예 응답하지 않거나, 심지어 재부팅되어야 하는 심각한 상황에 직면할 수 있습니다. 이러한 상황을 ‘커널 패닉’이라고도 부르며, 시스템 전체의 안정성을 위협합니다.

OOM Killer는 이런 최악의 상황을 방지하기 위해 존재합니다. 시스템 메모리가 고갈될 위험에 처했을 때, OOM Killer는 가장 적절하다고 판단되는 프로세스를 종료하여 메모리를 확보하고, 시스템이 완전히 멈추는 것을 막아줍니다. 즉, 시스템 전체를 보호하기 위해 특정 프로세스를 희생시키는 ‘최후의 보루’ 역할을 하는 것입니다.

OOM Killer의 프로세스 종료 기준 핵심 지표

OOM Killer는 `oom_score`라는 내부 점수를 기반으로 어떤 프로세스를 종료할지 결정합니다. 이 점수는 각 프로세스가 시스템 메모리를 얼마나 차지하고 있는지, 그리고 시스템에 얼마나 ‘나쁜’ 영향을 미치고 있는지를 수치화한 것입니다. 점수가 높을수록 OOM Killer의 타겟이 될 가능성이 커집니다.

`oom_score`는 여러 요소를 복합적으로 고려하여 계산됩니다. 주요 고려 사항은 다음과 같습니다.

• 메모리 사용량 가장 중요한 요소입니다. 현재 프로세스가 사용하고 있는 물리 메모리 양이 많을수록 `oom_score`는 높아집니다.

• 스왑 공간 사용량 스왑 공간은 물리 메모리가 부족할 때 하드디스크의 일부를 메모리처럼 사용하는 영역입니다. 스왑 공간을 많이 사용하는 프로세스는 메모리 압박에 기여한다고 판단되어 `oom_score`가 높아질 수 있습니다.
• 프로세스의 실행 시간 일반적으로 시스템에 오래 실행된 프로세스는 중요하다고 간주될 수 있지만, 때로는 메모리 누수 등으로 인해 오랜 시간 동안 메모리를 점유하고 있을 수도 있습니다. OOM Killer는 이러한 부분을 복합적으로 판단합니다.
• 프로세스 우선순위 (nice 값) `nice` 값은 프로세스의 CPU 사용 우선순위를 나타냅니다. OOM Killer는 `nice` 값과 직접적인 관계는 없지만, 시스템 자원 관리의 맥락에서 간접적으로 영향을 미칠 수 있습니다.
• 루트 권한 여부 루트 권한으로 실행되는 프로세스는 시스템의 핵심적인 역할을 수행할 가능성이 높으므로, 일반 사용자 프로세스보다 `oom_score`가 낮게 책정될 수 있습니다.
• `oom_score_adj` 값 이 값은 시스템 관리자가 직접 설정하여 프로세스의 `oom_score`를 조절할 수 있는 유일한 외부 조절 변수입니다. 이 값은 프로세스의 기본 `oom_score`에 더해지거나 빼져서 최종 `oom_score`에 영향을 미칩니다.

OOM Killer는 이 모든 요소를 종합하여 최종 `oom_score`가 가장 높은 프로세스부터 종료를 시도합니다.

관리자가 조절할 수 있는 OOM Score Adjustment

앞서 언급했듯이, `oom_score_adj`는 OOM Killer의 작동에 직접적으로 개입할 수 있는 강력한 도구입니다. 이 값은 `-1000`부터 `1000`까지 설정할 수 있으며, 기본값은 `0`입니다.

• `oom_score_adj`를 낮게 설정할수록 (예: -500, -1000) 해당 프로세스의 `oom_score`가 낮아져 OOM Killer의 타겟이 될 확률이 줄어듭니다. `-1000`으로 설정하면 해당 프로세스는 OOM Killer에 의해 절대 종료되지 않습니다.

• `oom_score_adj`를 높게 설정할수록 (예: 500, 1000) 해당 프로세스의 `oom_score`가 높아져 OOM Killer의 타겟이 될 확률이 커집니다.

이 설정을 통해 시스템 관리자는 데이터베이스 서버, 웹 서버 등 핵심 서비스가 메모리 부족 상황에서도 가능한 한 오래 유지되도록 보호하거나, 반대로 덜 중요한 프로세스를 먼저 종료되도록 유도할 수 있습니다.

실생활에서 OOM Killer를 이해하고 활용하는 방법

OOM Killer에 대한 이해는 시스템 관리자뿐만 아니라 일반 사용자에게도 유용합니다.

시스템 관리자 및 개발자를 위한 조언

• 메모리 모니터링은 필수입니다
  • `top`, `htop`, `free -h`, `vmstat`와 같은 도구를 사용하여 시스템의 메모리 사용량을 주기적으로 확인하세요. 특정 프로세스가 비정상적으로 메모리를 많이 사용하는지, 시스템 전체 메모리가 부족한 상태인지 파악하는 것이 중요합니다.
  • 메모리 사용량 추이를 그래프로 보여주는 모니터링 시스템(Prometheus, Grafana 등)을 구축하면 메모리 부족 현상을 사전에 감지하고 대응할 수 있습니다.
• `oom_score_adj`를 현명하게 사용하세요
  • 데이터베이스 서버, 웹 서버, 캐시 서버 등 시스템의 핵심 서비스 프로세스에는 낮은 `oom_score_adj` 값을 설정하여 보호하세요. 예를 들어, `echo -900 > /proc//oom_score_adj` 명령으로 특정 프로세스의 보호 수준을 높일 수 있습니다.
  • 개발 중인 불안정한 서비스나 테스트용 프로세스에는 높은 `oom_score_adj` 값을 부여하여 시스템 전체에 미치는 영향을 최소화할 수 있습니다.
• 충분한 스왑 공간을 확보하세요
  • 물리 메모리가 부족할 때 스왑 공간은 시스템이 완전히 멈추는 것을 방지하는 완충재 역할을 합니다. 적절한 스왑 공간(일반적으로 물리 메모리의 1배~2배)을 확보하는 것이 좋습니다.
• 메모리 누수 방지 코딩 습관
  • 개발자라면 자신이 작성하는 코드에서 메모리 누수가 발생하지 않도록 주의해야 합니다. 메모리 프로파일링 도구를 사용하여 애플리케이션의 메모리 사용 패턴을 분석하고 최적화하세요.
• 컨테이너 환경에서의 OOM Killer
  • Docker, Kubernetes와 같은 컨테이너 환경에서는 각 컨테이너에 할당된 메모리 제한(cgroup)이 중요합니다. 컨테이너가 할당된 메모리를 초과하면 컨테이너 내부의 OOM Killer가 작동하거나, 호스트의 OOM Killer가 해당 컨테이너를 종료할 수 있습니다. 각 컨테이너에 적절한 메모리 리밋을 설정하는 것이 중요합니다.

일반 사용자를 위한 팁

• 불필요한 프로그램 종료 습관
  • 컴퓨터가 느려지기 시작하면 사용하지 않는 웹 브라우저 탭이나 프로그램을 닫는 습관을 들이세요. 이는 메모리를 확보하여 OOM Killer가 작동할 가능성을 줄여줍니다.

• 시스템 로그 확인
  • 만약 프로그램이 갑자기 종료된다면, 시스템 로그(`dmesg` 명령이나 `/var/log/syslog`, `/var/log/messages` 파일)를 확인하여 OOM Killer 관련 메시지가 있는지 살펴보세요. 어떤 프로세스가 종료되었는지, 왜 종료되었는지 단서를 얻을 수 있습니다.

• 메모리 업그레이드 고려
  • 만약 OOM Killer가 너무 자주 작동한다면, 이는 시스템의 물리 메모리가 부족하다는 명백한 신호일 수 있습니다. 물리 메모리를 추가하는 것이 가장 근본적인 해결책이 될 수 있습니다.

흔한 오해와 사실 관계

• 오해 OOM Killer는 무작위로 프로세스를 종료한다.
  • 사실 OOM Killer는 `oom_score`라는 정교한 기준에 따라 가장 적절하다고 판단되는 프로세스를 종료합니다. 무작위가 아닙니다.

• 오해 OOM Killer는 항상 나쁘고 시스템에 문제를 일으킨다.
  • 사실 OOM Killer는 시스템이 완전히 마비되는 것을 막아주는 필수적인 방어 메커니즘입니다. 물론 특정 프로세스가 종료되는 것은 불편하지만, 시스템 전체의 안정성을 위해서는 불가피한 선택입니다.

• 오해 OOM Killer를 완전히 비활성화할 수 있고, 비활성화하는 것이 좋다.
  • 사실 `vm.oom-kill = 0` 또는 `oom_score_adj = -1000` 설정을 통해 OOM Killer의 작동을 제한할 수 있지만, 완전히 비활성화하는 것은 권장되지 않습니다. 메모리 부족 시 시스템이 완전히 멈추거나 커널 패닉에 빠질 위험이 매우 커집니다.

자주 묻는 질문과 답변

• OOM Killer가 실행되면 어떻게 알 수 있나요?
  • 시스템 로그(`dmesg`, `/var/log/syslog`, `/var/log/messages`)에서 “Out of memory”, “Killed process” 등의 키워드를 검색하면 OOM Killer가 어떤 프로세스를 종료했는지 확인할 수 있습니다.
• 특정 프로세스가 종료되지 않도록 설정할 수 있나요?
  • 네, 해당 프로세스의 `oom_score_adj` 값을 `-1000`으로 설정하면 OOM Killer에 의해 종료되지 않습니다. 하지만 이는 시스템 전체에 위험을 초래할 수 있으므로 신중하게 사용해야 합니다.
• 클라우드 환경에서는 OOM Killer가 어떻게 작동하나요?
  • 클라우드 환경의 가상 머신(VM)이나 컨테이너(Docker, Kubernetes)도 리눅스 커널을 기반으로 하므로 OOM Killer는 동일하게 작동합니다. 특히 컨테이너 환경에서는 각 컨테이너에 할당된 메모리 제한(cgroup)을 초과하면 OOM Killer가 발동하여 컨테이너가 종료될 수 있습니다.

비용 효율적인 OOM Killer 활용 방법

무조건적인 메모리 증설만이 OOM Killer 문제를 해결하는 유일한 방법은 아닙니다. 때로는 시스템 설정 최적화와 프로세스 관리를 통해 비용을 절감하면서도 안정성을 높일 수 있습니다.

• 리소스 최적화
  • 애플리케이션의 메모리 사용량을 분석하고 불필요한 리소스 낭비를 줄이는 것이 중요합니다. 메모리 누수를 해결하거나, 더 효율적인 알고리즘을 사용하는 등 소프트웨어적인 최적화는 하드웨어 증설 비용을 절감할 수 있는 가장 좋은 방법입니다.

• 서비스 우선순위 설정
  • `oom_score_adj`를 사용하여 중요 서비스(데이터베이스, 웹 서버 등)를 보호하고, 덜 중요한 서비스나 백그라운드 작업을 먼저 종료되도록 유도함으로써 제한된 메모리 자원을 효율적으로 배분할 수 있습니다. 이는 값비싼 고성능 서버를 구매하는 대신, 현재의 하드웨어에서 최대한의 효율을 끌어내는 방법입니다.

• 적절한 스왑 공간
  • 물리 메모리가 부족할 때 스왑 공간은 시스템이 완전히 멈추는 것을 방지합니다. 적절한 스왑 공간은 시스템의 탄력성을 높여 갑작스러운 메모리 스파이크에도 대응할 수 있게 하며, 이는 고가의 물리 메모리 추가 구매를 잠시 미루는 효과를 가져올 수 있습니다.

• 모니터링 및 알림 시스템 구축
  • 메모리 사용량을 지속적으로 모니터링하고, 임계값을 초과했을 때 관리자에게 알림을 주는 시스템을 구축하세요. 이는 OOM Killer가 발동하기 전에 문제를 예측하고 선제적으로 대응할 수 있게 하여, 시스템 다운타임을 줄이고 결과적으로 운영 비용을 절감하는 데 기여합니다.