OOM 관리

개요

Linux에서 Out Of Memory(OOM) 관리는 시스템 물리 메모리와 스왑이 모두 소진되었을 때 프로세스를 종료하여 시스템을 복구하는 메커니즘입니다. 커널은 oom-killer를 통해 가장 적합한 프로세스를 선택하여 종료하며, 이렇게 확보된 메모리는 시스템이 계속 동작할 수 있도록 사용됩니다.

OOM은 하드웨어 한계, 메모리 누수, 비정상 프로세스 등의 원인으로 발생할 수 있으며, 컨테이너와 클라우드 환경에서는 cgroup 단위의 OOM 관리가 중요합니다. 본 문서에서는 Linux OOM 관리의 동작 원리, oom_score 점수 체계, cgroup 통합, 관련 sysctl 튜닝, 그리고 사용자 공간 대응 도구를 분석합니다.

그림 1. Linux OOM 관리의 전체 구조와 관련 구성 요소

핵심 개념

OOM Killer 동작 원리

OOM Killer는 메모리가 부족할 때 프로세스를 종료하여 메모리를 확보하는 커널 메커니즘입니다. 커널은 __alloc_pages_may_oom() 함수를 통해 직접 회수(direct reclaim)와 백그라운드 회수(kswapd)가 모두 실패했을 때 OOM 상태로 판정합니다.

OOM Killer의 핵심 동작 순서는 다음과 같습니다:

1. 메모리 할당 실패 감지 (watermark 미달)
2. out_of_memory() 호출을 통한 OOM 상태 판정
3. 타겟 프로세스 선택 (oom_badness() 기반)
4. SIGKILL 전송을 통한 프로세스 종료
5. 메모리 해제 및 할당 재시도

그림 2. OOM Killer의 메모리 할당 실패부터 프로세스 종료까지의 동작 흐름

oom_score 점수 체계

OOM Killer는 각 프로세스에 점수를 매겨 가장 높은 점수를 가진 프로세스를 선택합니다. 점수는 프로세스의 메모리 사용량을 기반으로 계산되며, 다음 요소들이 반영됩니다:

• RSS (Resident Set Size): 실제 물리 메모리에 상주하는 페이지 수
• anon_rss: 익명 메모리(힙, 스택) 사용량
• file_rss: 파일 매핑 메모리 사용량
• swap_rss: 스왑에 있는 메모리 양
• oom_score_adj: 사용자가 설정한 보정값 (-1000 ~ 1000)

기본 공식에서 점수는 다음 비율로 가중치가 부여됩니다:

points = process_pages * 1000 / total_pages

메모리 사용량이 많을수록 점수가 높아지며, oom_score_adj를 통해 사용자가 직접 조정할 수 있습니다.

oom_score_adj 설정

/proc/<pid>/oom_score_adj 파일을 통해 개별 프로세스의 OOM 점수를 보정할 수 있습니다:

컨테이너 환경에서는 Kubernetes의 oom_score_adj를 통해 Pod 수준에서 조정할 수 있습니다.

cgroup OOM 통합

cgroup v2에서는 메모리 제한 초과 시 cgroup 단위의 OOM이 발생합니다. 주요 제어 파일은 다음과 같습니다:

• memory.max: cgroup의 메모리 하드 제한. 초과 시 OOM 발생
• memory.high: 하드 실패 전에 reclaim 압박을 먼저 유도하는 소프트 상한
• memory.low / memory.min: 중요한 워크로드를 reclaim으로부터 보호하는 보호선
• memory.oom.group: 1로 설정하면 cgroup 내 모든 프로세스를 함께 종료
• memory.swap.max: 스왑 사용량 제한. 스왑 없이 OOM 유도 가능
• memory.events: high, max, oom, oom_kill 카운터로 압박과 종료를 관측

cgroup OOM은 시스템 전체 OOM과 달리 해당 cgroup 내에서만 동작하며, 다른 cgroup이나 시스템 전체에는 영향을 미치지 않습니다. 실제 운영에서는 memory.high로 먼저 속도를 늦추고, 그래도 회복되지 않으면 memory.max 또는 memory.swap.max 경계에서 OOM이 발생하도록 설계하는 경우가 많습니다.

OOM Reaper와 사용자 공간 대응

커널이 희생 프로세스를 선택한 뒤에도 메모리 반환이 즉시 끝나는 것은 아닙니다. 이를 줄이기 위해 Linux는 oom_reaper 커널 스레드로 희생 프로세스의 주소 공간을 비동기로 정리해 메모리 회복 시간을 단축합니다. 이 단계가 없으면 큰 프로세스를 종료해도 allocator가 재시도할 때까지 회복 지연이 길어질 수 있습니다.

커널 OOM 이전 단계에서는 사용자 공간 데몬이 먼저 대응할 수 있습니다. systemd-oomd는 cgroup v2와 PSI(Pressure Stall Information)를 사용해 메모리 압박이 지속되는 cgroup을 골라 leaf cgroup 또는 memory.oom.group=1인 그룹 전체에 SIGKILL을 보냅니다. earlyoom은 MemAvailable과 swap 여유를 주기적으로 감시해 시스템이 livelock에 빠지기 전에 후보 프로세스를 먼저 종료합니다.

비교/분석

OOM 관리 정책 비교

메모리 제한 메커니즘 비교

운영 제어 지점 비교

동작 원리

OOM 감지 과정

커널은 메모리 할당 시점에 여러 단계를 거쳐 OOM 여부를 판단합니다:

1. Watermark 확인: 할당 시점에 free 페이지가 min watermark 미달인지 확인
2. 직접 회수(Direct Reclaim): 할당 호출자가 직접 LRU에서 페이지를 회수
3. kswapd 동작: 백그라운드 스레드가 watermark를 회복할 때까지 회수
4. COMPACT 재시도: 고차 할당 실패 시 메모리 압축 시도
5. OOM 판정: 모든 회수 메커니즘이 실패하면 out_of_memory() 호출

/proc/sys/vm/min_free_kbytes는 각 존(zone)에 대한 min watermark를 설정하며, 이 값이 OOM 발생 임계값에 직접적인 영향을 미칩니다.

vm.overcommit_memory=2 환경에서는 물리 메모리 고갈 전에 커밋 한도 초과가 먼저 실패 원인이 될 수 있습니다. 반대로 heuristic overcommit 모드에서는 할당 자체는 통과했더라도 실제 page fault 시점에 reclaim이 실패하면서 OOM으로 이어질 수 있습니다.

타겟 프로세스 선택 알고리즘

OOM Killer는 oom_badness() 함수를 사용하여 대상 프로세스를 선택합니다:

1. 시스템 전체 프로세스 목록 순회
2. 각 프로세스의 oom_score 계산 (메모리 사용량 기반)
3. oom_score_adj를 통해 보정된 최종 점수 산출
4. 가장 높은 점수를 가진 프로세스 선택
5. oom_score_adj가 -1000인 프로세스는 후보에서 제외
6. 여러 프로세스가 동일 점수일 경우 PID가 높은 프로세스 우선

그림 3. OOM Killer의 타겟 프로세스 선택 알고리즘 흐름

시스템 전체 OOM과 memcg OOM은 후보 집합이 다릅니다. 시스템 전체 OOM은 시스템 전역 task list를 보지만, memcg OOM은 해당 메모리 cgroup 안의 태스크만 후보로 삼습니다. 따라서 컨테이너 환경에서는 전역 oom_score_adj보다 cgroup 경계와 memory.oom.group 설정이 실제 종료 결과에 더 직접적인 영향을 줄 수 있습니다.

커널 메모리 할당과 OOM 관계

Linux 메모리 할당은 존(zone) 기반으로 동작하며, 각 존은 watermark(min, low, high)를 가지고 있습니다:

• WMARK_MIN: 이 이하로 내려가면 직접 회수 시작
• WMARK_LOW: kswapd가 이 수준까지 회복하면 동작 중단
• WMARK_HIGH: 완전한 여유 상태

할당 실패 시 OOM까지의 과정은 할당 요청의 GFP 플래그에 따라 달라지며, __GFP_NOFAIL을 지정한 할당은 무한히 재시도합니다.

OOM 이후에는 희생 프로세스에 TIF_MEMDIE가 부여되어 메모리 해제 경로를 빠르게 통과하도록 돕고, oom_reaper가 주소 공간을 정리해 allocator 재시도 성공 확률을 높입니다. 이 때문에 운영자는 단순히 "누가 죽었는가"뿐 아니라 dmesg, memory.events, oomctl을 함께 확인해 실제 병목이 전역 OOM인지 특정 cgroup OOM인지 구분해야 합니다.

장단점

장점

• 시스템 전체 다운을 방지하고 커널을 계속 동작시킵니다.
• 메모리 사용량이 가장 많은 프로세스를 자동으로 선택합니다.
• oom_score_adj를 통해 중요 프로세스를 보호할 수 있습니다.
• cgroup 통합으로 컨테이너 환경에서도 동작합니다.
• 다양한 사용자 공간 도구(earlyoom, systemd-oomd)로 보완 가능합니다.

단점

• OOM Killer 동작 시 예기치 않은 프로세스 종료가 발생할 수 있습니다.
• 데이터베이스나 상태를 유지하는 서비스는 종료 시 데이터 손실 위험이 있습니다.
• 과도한 메모리 사용 프로세스가 항상 가장 높은 점수를 받는 것은 아닙니다.
• 커널 메모리(slab, 스택)는 OOM에 직접적으로 영향을 받지 않습니다.
• oom_score 계산은 메모리 사용량 기반이므로, 메모리를 적게 쓰는 프로세스가 살 수 있습니다.

관련 기술

• Linux 메모리 관리 기초: 리눅스 메모리 관리 기본 개념
• cgroup 메모리: 컨테이너 환경의 메모리 제어
• 스왑/zRAM: 스왑과 zRAM을 통한 메모리 확장
• Linux 메모리 최적화: 메모리 최적화 기법
• oomctl, systemd-cgls, systemd-cgtop: systemd 기반 cgroup/OOM 관측 도구
• /proc/<pid>/oom_score, /proc/<pid>/oom_score_adj, /sys/fs/cgroup/*/memory.events: OOM 후보와 cgroup 이벤트 확인 지점
• Linux Kernel Documentation: Out-Of-Memory (Documentation/mm/oom.rst)
• Linux Kernel Documentation: PSI (Documentation/accounting/psi.rst)
• Linux Kernel Documentation: /proc/sys/vm/ (Documentation/admin-guide/sysctl/vm.rst)
• Linux Kernel Documentation: Control Group v2 (Documentation/admin-guide/cgroup-v2.rst)
• earlyoom 프로젝트: https://github.com/rfjakob/earlyoom
• systemd-oomd: https://www.mankier.com/8/systemd-oomd

핵심 정리

Linux OOM 관리는 시스템 메모리가 완전히 소진되었을 때 커널이 자동으로 프로세스를 종료하여 시스템을 복구하는 최후의 방어 수단입니다. OOM Killer는 oom_score와 oom_score_adj를 바탕으로 후보를 고르고, 종료 뒤에는 oom_reaper가 메모리 회복 지연을 줄입니다. cgroup v2 환경에서는 memory.high로 먼저 압박을 완화하고 memory.max 및 memory.oom.group으로 격리 경계를 명확히 하는 구성이 중요합니다. 실제 운영에서는 dmesg, memory.events, oomctl을 함께 봐서 시스템 전체 OOM과 cgroup OOM을 구분해야 하며, systemd-oomd나 earlyoom으로 커널 OOM 이전에 선제 대응하는 전략이 많이 쓰입니다.