리눅스 커널의 최후의 보루: OOM Killer

Ⅰ. OOM Killer(Out Of Memory Killer) 이란?

OOM Killer는 리눅스 커널이 시스템의 물리적 메모리와 스왑(Swap) 공간이 모두 고갈되어 더 이상 정상적인 운영이 불가능한 상태(Out Of Memory)에 빠졌을 때 가동되는 비상 보호 메커니즘입니다.

ⅰ. 개념 및 정의

1. 시스템 마비를 막기 위해 커널이 직접 개입하여 메모리를 과도하게 점유하고 있는 특정 프로세스를 강제로 종료시키는 기능입니다.
2. 한정된 자원 속에서 가장 덜 중요하면서도 자원을 많이 소모하는 프로세스를 '희생양'으로 삼아 여유 메모리를 확보합니다.

ⅱ. 기술의 목적

1. 시스템 전체가 먹통이 되는 커널 패닉(Kernel Panic)을 방지하고 운영체제의 핵심 기능을 유지합니다.
2. 서버 장비의 강제 재부팅 없이도 시스템이 스스로 회복하여 다른 중요 서비스들이 계속 동작할 수 있도록 생존을 도모합니다.

Ⅱ. OOM Killer(Out Of Memory Killer) 특징

OOM Killer는 무작정 아무 프로세스나 죽이는 것이 아니라, 철저하게 계산된 점수 기반 시스템을 통해 타겟을 선정합니다.

ⅰ. 점수 기반의 희생양 선정 (Badness Score)

1. 커널 내부의 휴리스틱 알고리즘을 통해 실행 중인 모든 프로세스에 'Badness Score(oom_score)'를 계산하여 부여합니다.
2. 프로세스가 점유한 메모리가 클수록 점수가 높아지며, 이 점수가 가장 높은 프로세스가 1순위 타겟이 됩니다.

ⅱ. 중요 시스템 프로세스 보호

1. 시스템 유지에 필수적인 루트(Root) 권한의 프로세스나 하드웨어 관리 데몬 등은 상대적으로 낮은 점수를 부여받아 보호됩니다.
2. 주로 사용자 공간(User Space)에서 실행된 무거운 애플리케이션이나 메모리 누수(Leak)가 발생한 프로세스가 주된 타겟이 됩니다.

Ⅲ. OOM Killer(Out Of Memory Killer) 동작방식

메모리가 고갈되는 시점부터 타겟을 찾아 강제 종료하기까지 커널 내부의 동작 메커니즘은 다음과 같습니다.

ⅰ. 메모리 고갈 감지

1. 시스템의 가용 메모리가 최소 워터마크(min_free_kbytes) 아래로 떨어지면, 먼저 kswapd 데몬이 캐시를 비우고 스왑 아웃(Swap-out)을 시도합니다.
2. 이 과정에서도 충분한 메모리를 확보하지 못해 새로운 메모리 할당 요청을 처리할 수 없게 되면 커널은 OOM 상태를 선언합니다.

ⅱ. 타겟 프로세스 스캐닝 및 점수 계산

1. 커널은 out_of_memory() 함수를 호출한 뒤, select_bad_process() 함수를 통해 현재 실행 중인 모든 태스크를 순회합니다.
2. 각 프로세스의 메모리 사용량, 실행 시간, 자식 프로세스의 유무, 사용자가 설정한 가중치 등을 종합하여 최종 oom_score를 산출합니다.

ⅲ. 프로세스 강제 종료 (Kill)

1. 가장 높은 점수를 받은 불량 프로세스(Bad Process)가 선정되면 커널은 해당 프로세스에 SIGKILL (9번) 시그널을 즉시 전송합니다.
2. 프로세스는 어떠한 에러 처리도 하지 못한 채 즉시 강제 종료되며, 점유하고 있던 모든 메모리 자원이 커널에 반환되어 시스템이 안정화됩니다.

Ⅳ. OOM Killer(Out Of Memory Killer) 흐름도

OOM Killer가 발동하여 시스템 메모리를 회수하는 전체 과정을 시각화한 흐름도입니다.

 

ⅰ. 아키텍처 흐름의 핵심 요약

1. 메모리 부족 상황에서 일반적인 페이징 교체 작업(kswapd)이 먼저 방어벽 역할을 수행합니다.
2. 이 방어벽이 뚫렸을 때 비로소 커널 내부에 하드코딩된 OOM Killer 로직이 최후의 수단으로 개입하게 됩니다.

Ⅴ. OOM Killer(Out Of Memory Killer) 설치 방법

OOM Killer는 별도로 설치하는 프로그램이 아니며, 리눅스 시스템의 근간을 이루는 설정과 연관되어 있습니다.

ⅰ. 커널 내장 모듈

1. OOM Killer는 리눅스 커널에 기본적으로 내장된 핵심 기능이므로 OS 설치와 동시에 자동으로 활성화되어 동작 대기 상태가 됩니다.
2. 별도의 패키지 매니저(apt, yum 등)를 통한 설치 작업이 필요하지 않습니다.

ⅱ. 동작 모드 설정 (Overcommit)

1. /proc/sys/vm/overcommit_memory 파일의 값을 조절하여 시스템이 물리 메모리 이상을 프로세스에 할당(Overcommit)할 수 있도록 허용할지 여부를 결정합니다.
2. 이 값이 0(기본값, Heuristic)이나 1(Always)로 설정되어 있어야 메모리 초과 할당이 발생하고 OOM Killer가 정상적으로 개입할 수 있습니다.

Ⅵ. OOM Killer(Out Of Memory Killer) 기술 사용 방법

시스템 관리자는 특정 프로세스가 OOM Killer에 의해 억울하게 죽는 것을 막거나, 반대로 특정 프로세스를 1순위로 죽이도록 점수를 튜닝할 수 있습니다.

ⅰ. oom_score_adj 조정 (수동 타겟팅 및 보호)

1. 프로세스를 보호하려면 터미널에서 echo -500 > /proc/[PID]/oom_score_adj 명령어를 입력하여 점수를 대폭 낮춥니다. (최소값 -1000은 OOM 예외 처리)
2. 반대로 메모리 부족 시 가장 먼저 종료시키고 싶은 캐시 프로세스 등에는 양수 값(예: 500)을 부여하여 타겟 우선순위를 높일 수 있습니다.

ⅱ. Systemd 서비스 스크립트에 영구 적용

1. 데몬 서비스가 재시작될 때마다 점수가 유지되도록 하려면 .service 유닛 파일 구성 시 [Service] 섹션에 OOMScoreAdjust=-500과 같이 명시합니다.
2. 이를 통해 MySQL이나 Nginx 같은 중요 서비스가 예상치 못한 메모리 부족 현상에도 살아남도록 생존력을 높입니다.

Ⅶ. OOM Killer(Out Of Memory Killer) 자주 쓰는 명령어

운영 서버에서 갑자기 프로세스가 사라졌을 때 OOM을 의심하고 분석하기 위해 필수적인 명령어들입니다.

ⅰ. 커널 로그에서 OOM 발동 이력 확인

1. dmesg -T | grep -i oom : 서버 부팅 이후 기록된 커널 로그에서 OOM Killer가 발동한 정확한 시간과 관련 메시지를 필터링하여 출력합니다.
2. grep -i "killed process" /var/log/messages : 시스템 로그 파일에서 강제 종료된 희생양 프로세스의 이름과 PID 내역을 추적합니다. (Ubuntu/Debian은 /var/log/syslog 확인)

ⅱ. 프로세스별 OOM 점수 및 상태 점검

1. cat /proc/[PID]/oom_score : 해당 프로세스가 현재 커널로부터 부여받은 최종 타겟 점수를 실시간으로 확인합니다.
2. cat /proc/[PID]/oom_score_adj : 관리자 또는 시스템에 의해 수동으로 부여된 가중치(조정값)가 얼마인지 점검합니다.

Ⅷ. OOM Killer(Out Of Memory Killer) 활용방안

이 메커니즘을 영리하게 활용하면 클라우드 및 엔터프라이즈 환경에서 시스템 가용성을 극대화할 수 있습니다.

ⅰ. 핵심 인프라 및 관리 도구 보호

1. SSH 데몬(sshd)의 OOM 점수를 낮춰서 시스템이 극도의 부하 상태에 빠지더라도 관리자가 원격으로 접속해 조치할 수 있는 '백도어'를 살려둡니다.
2. 클라우드 환경에서 노드의 상태를 중앙으로 전송하는 모니터링 에이전트(Datadog, Zabbix 등)가 죽지 않도록 보호하여 장애 관제 시야를 유지합니다.

ⅱ. 컨테이너(Docker/K8s) 오케스트레이션 적용

1. 쿠버네티스(Kubernetes) 환경에서는 파드(Pod)에 설정된 리소스 요청/제한 값에 따라 Guaranteed, Burstable, BestEffort 등의 QoS 클래스가 나뉩니다.
2. 이 QoS 등급에 따라 컨테이너 내부의 oom_score_adj가 자동 할당되며, 이를 통해 중요도가 낮은 배치 작업 파드부터 안전하게 먼저 축출(Eviction)되도록 클러스터를 운영합니다.

Ⅸ. OOM Killer(Out Of Memory Killer) 기술 트러블 슈팅

OOM Killer가 발동했다는 것은 시스템 메모리 관리에 심각한 적신호가 켜졌다는 의미이므로 정확한 사후 대처가 필수적입니다.

ⅰ. 원인 분석 및 범인 식별

1. 웹 서버나 DB 프로세스가 특별한 애플리케이션 에러 로그 없이 사라졌다면, 가장 먼저 dmesg를 통해 OOM 기록을 확인하여 원인을 식별해야 합니다.
2. 로그에 남은 태스크 상태 정보에서 Total-VM(가상 메모리 총량)과 Anon-RSS(익명 페이지 실사용량) 수치가 비정상적으로 높은 프로세스를 찾아 메모리 누수(Leak) 발생 여부를 확인합니다.

ⅱ. 해결 및 예방 조치

1. 하드웨어 및 인프라 확장: 빈번하게 OOM이 발생한다면 절대적인 메모리 풀이 부족한 것이므로 물리적인 RAM을 증설하거나 스왑(Swap) 파일 용량을 확장해야 합니다.
2. 애플리케이션 튜닝 제한: Java(JVM) 기반 애플리케이션은 힙 메모리 최댓값(-Xmx)을 물리 메모리의 70% 이하로 엄격하게 제한하여, 앱 차원의 OutOfMemoryError로 끝나게 유도하고 리눅스 전체 커널 레벨의 OOM Killer 발동을 사전에 차단합니다.