OOM Killer가 발생하는 이유

메모리가 충분한데도 OOM Killer가 발생하는 이유

컴퓨터를 사용하거나 서버를 운영하다 보면 시스템이 갑자기 멈추거나 특정 프로세스가 강제로 종료되는 현상을 경험하게 됩니다. 리눅스 환경에서 흔히 발생하는 이 현상의 주범은 바로 ‘OOM Killer(Out of Memory Killer)’입니다. 많은 사용자가 “작업 관리자를 확인해보니 메모리 여유 공간이 충분한데 왜 프로세스가 죽었을까?”라는 의문을 갖곤 합니다. OOM Killer는 단순히 메모리가 0이 되었을 때만 작동하는 것이 아니며, 시스템의 안정성을 유지하기 위한 복잡한 메커니즘을 가지고 있습니다.

OOM Killer가 작동하는 기본 원리

OOM Killer는 리눅스 커널의 핵심 기능 중 하나입니다. 시스템의 물리적 메모리가 고갈되어 더 이상 새로운 메모리 할당 요청을 처리할 수 없는 위기 상황에서, 커널은 시스템 전체의 붕괴(Kernel Panic)를 막기 위해 특정 프로세스를 강제로 종료합니다. 이때 커널은 점수를 매겨 가장 ‘희생시키기 적절한’ 프로세스를 선택합니다. 메모리를 많이 점유하고 있거나, 시스템의 핵심 기능이 아닌 프로세스가 우선적인 타겟이 됩니다.

메모리가 충분해 보여도 OOM Killer가 발생하는 이유

사용자가 확인하는 메모리 수치와 커널이 판단하는 메모리 여유분 사이에는 괴리가 있을 수 있습니다. 다음은 메모리가 남아 있음에도 불구하고 OOM Killer가 발생하는 대표적인 이유들입니다.

가상 메모리와 물리적 메모리의 차이

대부분의 운영체제는 가상 메모리 기술을 사용합니다. 프로세스는 실제 물리 메모리보다 더 큰 가상 주소 공간을 할당받을 수 있습니다. 애플리케이션이 메모리 할당을 요청할 때 커널은 일단 승인하지만, 실제로 그 메모리를 사용하려고 접근하는 순간 물리 메모리에 매핑합니다. 만약 시스템 전체의 물리 메모리가 부족해지면, 가상 메모리상으로는 여유가 있어 보여도 실제 물리적 공간을 확보하지 못해 OOM Killer가 발동합니다.

커널의 메모리 예약과 오버커밋 정책

리눅스 커널에는 ‘Overcommit’이라는 정책이 있습니다. 이는 프로세스가 실제 필요한 것보다 더 많은 메모리를 요청할 수 있도록 허용하는 기술입니다. 커널은 모든 프로세스가 할당받은 메모리를 동시에 100% 사용하지 않을 것이라는 전제하에 운영됩니다. 하지만 예상외로 많은 프로세스가 동시에 메모리를 사용하기 시작하면, 커널은 예약된 메모리를 감당하지 못하고 OOM Killer를 호출하게 됩니다. 즉, ‘사용 가능한 메모리’가 수치상으로는 보여도 ‘예약된 메모리’가 이미 한계치에 도달한 상태인 것입니다.

메모리 단편화 문제

메모리는 연속된 공간으로 할당되어야 효율적입니다. 시스템을 오래 사용하다 보면 메모리 공간이 조각조각 나뉘는 ‘단편화’ 현상이 발생합니다. 전체적인 메모리 총량은 충분해 보일지라도, 특정 프로세스가 필요로 하는 연속된 대용량 메모리 블록을 할당할 수 없는 상황이 되면 커널은 이를 메모리 부족으로 간주하고 OOM Killer를 작동시킬 수 있습니다.

파일 캐시와 버퍼의 오해

운영체제는 성능 향상을 위해 사용하지 않는 메모리를 파일 시스템 캐시나 버퍼로 활용합니다. ‘free’ 명령어로 확인했을 때 캐시 영역이 메모리를 많이 점유하고 있는 것처럼 보일 수 있습니다. 때로는 커널이 이 캐시를 즉각적으로 해제하지 못하거나, 특정 애플리케이션이 캐시를 압도할 만큼의 메모리를 급격히 요구할 때 시스템은 메모리 부족 상태로 판단하게 됩니다.

OOM Killer를 관리하고 예방하는 실용적인 방법

시스템 안정성을 높이고 원치 않는 프로세스 종료를 방지하기 위해 다음과 같은 전략을 활용할 수 있습니다.

프로세스별 OOM 점수 조정하기

리눅스에서는 각 프로세스마다 OOM Killer가 선택할 우선순위를 조정할 수 있습니다. 중요한 서비스(예: 데이터베이스, 웹 서버)가 갑자기 종료되는 것을 방지하려면 해당 프로세스의 OOM 점수를 낮추면 됩니다.

• 프로세스 ID를 확인한 후 /proc/[PID]/oom_score_adj 파일을 통해 점수를 조정합니다.

• -1000으로 설정하면 해당 프로세스는 OOM Killer의 대상에서 영구적으로 제외됩니다.

메모리 오버커밋 설정 변경

/proc/sys/vm/overcommit_memory 설정을 변경하여 커널의 메모리 할당 정책을 제어할 수 있습니다.

• 0: 커널이 휴리스틱하게 판단하여 오버커밋을 허용합니다 (기본값).

• 1: 항상 오버커밋을 허용합니다.
• 2: 물리적 메모리와 스왑 영역의 합계를 초과하는 할당을 거부합니다. 안정성을 최우선으로 한다면 2로 설정하는 것이 좋습니다.

스왑 메모리 활용

물리적 메모리가 부족할 때 하드디스크나 SSD의 일부를 메모리처럼 사용하는 스왑(Swap) 공간은 OOM Killer를 늦추거나 방지하는 훌륭한 완충재 역할을 합니다. 스왑 공간이 전혀 없다면 물리 메모리가 꽉 차는 순간 바로 OOM Killer가 작동하지만, 적절한 스왑이 있으면 시스템이 숨을 쉴 수 있는 시간을 벌 수 있습니다.

흔한 오해와 사실 관계

오해: 메모리 누수만이 OOM Killer의 원인이다

많은 이들이 메모리 누수(Memory Leak)를 OOM Killer의 유일한 원인으로 생각합니다. 물론 누수는 주된 원인이지만, 앞서 언급한 커널의 정책, 시스템 설정, 그리고 예상치 못한 트래픽 급증에 따른 메모리 요구량 폭증 등 다양한 요인이 복합적으로 작용합니다.

사실: 메모리 사용량이 낮아도 죽을 수 있다

실제 사용 중인 메모리(RSS)는 적더라도, 해당 프로세스가 요청해둔 가상 메모리 공간이 시스템 전체 용량을 넘어서면 커널은 해당 프로세스를 위험 요소로 간주할 수 있습니다. 따라서 ‘사용 중인 메모리’만 모니터링하는 것은 불충분합니다.

전문가의 조언 및 시스템 모니터링 팁

시스템 관리 전문가들은 단순히 메모리 점유율을 보는 것보다 ‘메모리 압박(Memory Pressure)’ 지표를 확인하라고 조언합니다. 리눅스 커널 4.20부터 도입된 PSI(Pressure Stall Information) 기능을 활용하면 시스템이 메모리 부족으로 인해 얼마나 지연되고 있는지 실시간으로 파악할 수 있습니다.

또한, 서버 운영 시에는 다음 체크리스트를 주기적으로 확인하는 것이 좋습니다.

• dmesg 또는 /var/log/syslog를 확인하여 OOM Killer가 실제 어떤 프로세스를 종료했는지 로그를 분석합니다.
• 애플리케이션의 메모리 제한 설정을 명확히 합니다. (예: Java의 경우 Xmx 옵션 등을 통해 힙 메모리 크기를 적절히 제한)
• 모니터링 도구(Prometheus, Grafana 등)를 통해 메모리 사용량뿐만 아니라 Swap 사용량과 페이지 폴트(Page Fault) 빈도를 함께 모니터링합니다.

자주 묻는 질문

질문: OOM Killer가 발생하지 않게 완전히 막을 수 있나요?

답변: 이론적으로는 가능할 수 있으나 권장하지 않습니다. OOM Killer는 시스템 전체가 멈추는 상황에서 최후의 수단으로 작동합니다. 이를 완전히 비활성화하면 메모리 부족 시 시스템 전체가 완전히 먹통이 되어 재부팅 외에는 해결 방법이 없는 상태가 될 수 있습니다.

질문: 메모리를 증설했는데도 여전히 OOM Killer가 돕니다. 왜 그런가요?

답변: 메모리 증설은 근본적인 해결책이 아닐 수 있습니다. 애플리케이션의 메모리 누수가 심각하거나, 잘못된 설정으로 인해 무한정 메모리를 점유하려는 프로세스가 있다면 물리 메모리를 늘려도 결국 한계에 도달하게 됩니다. 로그를 통해 어떤 프로세스가 메모리를 독점하고 있는지 먼저 파악해야 합니다.

시스템은 유기적으로 연결된 거대한 생태계와 같습니다. 메모리가 남아 있음에도 OOM Killer가 작동하는 이유는 시스템이 여러분이 생각하는 것보다 훨씬 더 엄격하게 자원을 관리하고 있기 때문입니다. 시스템의 메모리 관리 정책을 이해하고 적절한 설정을 적용한다면, 예기치 못한 서비스 중단 사고를 크게 줄일 수 있을 것입니다.