지식
Linux

OOM Killer — 메모리 부족 시 리눅스가 프로세스를 선택하는 방법

Linux OOM Killer의 동작 원리, oom_score·oom_score_adj 계산, dmesg 로그 분석, 중요 서비스 보호 방법, overcommit 설정, earlyoom 활용법을 설명합니다.

· 6 min read · PALDYN Team

지난 글에서 페이지 캐시가 메모리를 관리하는 방식을 살펴봤습니다. 이번에는 메모리가 완전히 바닥날 때 리눅스가 취하는 극단적인 조치인 OOM Killer(Out-Of-Memory Killer)를 알아봅니다.

OOM이란

리눅스는 기본적으로 메모리 오버커밋을 허용합니다. malloc()으로 4GB를 할당해도 실제 접근 전까지는 물리 메모리를 사용하지 않습니다. 하지만 여러 프로세스가 실제로 대규모 메모리를 사용하기 시작하면 물리 RAM과 스왑이 모두 소진됩니다.

이 상황에서 커널은 새 메모리 할당 요청을 거부하거나 일부 프로세스를 강제 종료하는 선택을 해야 합니다. 후자를 담당하는 것이 OOM Killer입니다.

OOM Killer 동작 원리

oom_score — 희생 대상 결정

OOM Killer는 각 프로세스에 oom_score (0~1000)를 부여합니다. 점수가 높을수록 먼저 종료됩니다.

# 특정 프로세스의 oom_score 확인
cat /proc/1234/oom_score

# 전체 프로세스 oom_score 순위
for p in /proc/[0-9]*/oom_score; do
  awk -v f="$p" '{print $1, f}' "$p"
done | sort -rn | head -10

점수 계산 요소:

  • 메모리 사용량이 많을수록 높은 점수
  • 자식 프로세스 메모리도 포함
  • root 프로세스는 약간 낮은 점수
  • 오래 실행된 프로세스는 약간 낮은 점수

oom_score_adj — 수동 조정

/proc/PID/oom_score_adj에 -1000~1000 범위의 값을 쓰면 점수를 조정할 수 있습니다.

# 중요 서비스 보호 (낮은 점수)
echo -900 | sudo tee /proc/$(pgrep nginx)/oom_score_adj

# 절대 종료하지 않음 (-1000)
echo -1000 | sudo tee /proc/1/oom_score_adj

# 테스트/덜 중요한 프로세스 (높은 점수)
echo 500 | sudo tee /proc/$TEST_PID/oom_score_adj

systemd 서비스에서 영구 설정:

# /etc/systemd/system/myservice.service
[Service]
OOMScoreAdjust=-900

OOM Killer 제어

OOM 발생 감지

# 커널 로그에서 OOM 확인
sudo dmesg -T | grep -i 'oom\|killed' | tail -20

# systemd 저널 (더 보기 좋음)
sudo journalctl -k | grep -i 'out of memory\|killed process'

# 실시간 모니터링
sudo dmesg --follow | grep -i oom

OOM 로그 예시:

[Thu May 26 10:12:34 2026] Out of memory: Kill process 12345 (java) score 450 or sacrifice child
[Thu May 26 10:12:34 2026] Killed process 12345 (java) total-vm:2048000kB, anon-rss:1024000kB, file-rss:0kB

total-vm은 가상 메모리 크기, anon-rss는 실제 점유한 익명 페이지입니다.

메모리 오버커밋 설정

# 현재 오버커밋 모드 확인
cat /proc/sys/vm/overcommit_memory

# 0 (기본): 경험적 오버커밋 허용 (대부분의 malloc 허용)
# 1: 무조건 허용 (malloc이 절대 실패 안 함)
# 2: 제한 모드 (물리 RAM + swap의 N%만 허용)

# 오버커밋 비율 설정 (모드 2에서)
cat /proc/sys/vm/overcommit_ratio  # 기본 50 (50%)

Redis는 vm.overcommit_memory=1을 권장합니다. 백그라운드 저장(RDB)이 fork() 시 CoW로 메모리를 많이 쓰기 때문입니다.

# Redis 권장 설정
sudo sysctl vm.overcommit_memory=1

cgroup으로 메모리 한도

OOM Killer보다 예방적인 방법입니다. cgroup v2로 프로세스 그룹의 메모리를 제한합니다.

# systemd 서비스에서 메모리 한도
# /etc/systemd/system/myapp.service
# [Service]
# MemoryMax=512M
# MemoryHigh=400M  # 소프트 한도 (회수 촉진)

# 컨테이너 (Docker)
docker run --memory=512m --memory-swap=512m myapp

# cgroup v2 직접 설정
echo 536870912 > /sys/fs/cgroup/myapp/memory.max

한도 초과 시 해당 cgroup 내에서만 OOM Killer가 작동하여 다른 서비스에 영향을 주지 않습니다.

earlyoom — 더 스마트한 종료

커널 OOM Killer는 시스템이 이미 메모리 스래싱 상태에 빠진 후에야 발동합니다. earlyoom은 메모리 사용률이 임계값에 도달하면 미리 프로세스를 종료합니다.

# 설치
sudo apt install earlyoom

# 설정: 메모리 5% 이하, 스왑 5% 이하일 때 작동
# /etc/default/earlyoom
# EARLYOOM_ARGS="-m 5 -s 5 --avoid '(^|/) (init|sshd|systemd)'

sudo systemctl enable --now earlyoom

earlyoom은 SIGTERM을 먼저 보내 정상 종료할 기회를 주고, 응답 없으면 SIGKILL을 보냅니다. 커널 OOM Killer는 바로 SIGKILL을 씁니다.

트러블슈팅 시나리오

서버에서 프로세스가 갑자기 죽었을 때:

# 1. OOM 여부 확인
sudo dmesg -T | grep -E 'oom|killed' | tail -20

# 2. 어떤 프로세스가 많은 메모리를 쓰는지
ps aux --sort=-%mem | head -15

# 3. 현재 메모리 상태
free -h && cat /proc/meminfo | grep -E 'Cached|Dirty|Writeback|MemAvailable'

# 4. oom_score 높은 프로세스 목록
for p in /proc/[0-9]*/oom_score; do
  awk -v f="$p" '{if ($1 > 100) print $1, f}' "$p" 2>/dev/null
done | sort -rn | head -10

지난 글: Page Cache — 리눅스 메모리 캐시의 핵심 구조

다음 글: Container Namespaces 상세 — 컨테이너 격리의 실제 구현


읽어주셔서 감사합니다. 😊