OOM Killer가 프로세스를 죽였다 — dmesg로 확인하고 대응 | 기술노트

핵심 요약

프로세스가 로그도 없이 갑자기 Killed되고 사라졌다면, 리눅스 OOM(Out Of Memory) Killer가 메모리 부족 상황에서 강제 종료했을 가능성이 크다. 커널이 SIGKILL로 죽이기 때문에 앱은 유언도 못 남긴다. 증거는 dmesg에 있다.

1. 범인 확인

dmesg -T | grep -i "killed process"
# 또는
journalctl -k | grep -i oom

Out of memory: Killed process 1234 (node)
 total-vm:2100000kB, anon-rss:1800000kB ...

"Killed process ... (node)"가 보이면 OOM Killer가 그 프로세스를 골라 죽인 것이다.

2. 왜 하필 그 프로세스를?

커널은 각 프로세스에 oom_score를 매겨 메모리를 가장 많이 쓰는(그리고 점수가 높은) 것을 희생시킨다. 그래서 정작 메모리를 많이 쓰는 앱이 죽는 게 보통이지만, 때로는 엉뚱한 프로세스가 걸리기도 한다.

3. 근본 원인 파악

확인	명령
현재 메모리	`free -h`
프로세스별 사용	`ps aux --sort=-%mem \| head`
스왑 여부	`swapon --show`
컨테이너 제한	`cat /sys/fs/cgroup/memory.max`

4. 대응

메모리 누수면 앱을 고친다(가장 근본적) — 힙 스냅샷·프로파일러로 추적
스왑 추가로 급한 불 끄기(성능 저하는 감수)
Docker/K8s면 --memory·requests/limits를 실제 사용량에 맞게 조정
중요 프로세스는 oom_score_adj를 낮춰 우선 보호(echo -1000 > /proc/PID/oom_score_adj)

5. 함정

컨테이너는 호스트 전체가 아니라 cgroup 제한에서 OOM이 난다 — 호스트 메모리는 여유여도 컨테이너 한도 초과면 죽음
메모리를 무작정 늘리면 누수를 가릴 뿐 — 사용량이 계속 우상향이면 코드 문제

자주 묻는 질문

앱이 Killed만 뜨고 아무 로그가 없어요.

OOM Killer는 SIGKILL로 즉시 종료해 앱이 종료 핸들러를 실행할 틈이 없습니다. 그래서 앱 로그엔 흔적이 없고 커널 로그(dmesg, journalctl -k)에만 남습니다. 거기서 "Killed process"를 확인하세요.

스왑을 늘리면 해결되나요?

OOM 발생 빈도는 줄지만 근본 해결은 아닙니다. 스왑은 디스크라 성능이 크게 떨어지고, 누수가 있으면 결국 다시 터집니다. 급한 완화책으로 쓰고 원인(누수·과소 산정된 메모리 한도)을 함께 잡아야 합니다.

컨테이너는 호스트 메모리가 넉넉한데 왜 OOM이 나나요?

컨테이너는 cgroup의 memory 한도 안에서 동작합니다. 호스트 전체가 여유여도 컨테이너에 할당된 한도를 초과하면 그 컨테이너 안에서 OOM이 발생합니다. limits 설정을 실제 사용량에 맞게 올리세요.