16강 / 20강

메모리가 모자랄 때 — 스왑과 OOM Killer

free 를 제대로 읽고, 워커 메모리를 계산한다

새벽 3시에 알림이 옵니다. "쇼핑몰이 죽었어요."

로그를 보니 이렇게 적혀 있습니다.

kernel: Out of memory: Killed process 1046 (gunicorn) total-vm:1214MB, anon-rss:892MB

커널이 여러분의 앱을 죽였습니다. 왜 그랬고, 어떻게 막을까요?

고등학생스왑과 OOM Killer

메모리가 모자라면 두 가지가 차례로 일어납니다.

순서	일어나는 일	결과
1	스왑 — 디스크로 밀어낸다	느려진다
2	OOM Killer — 프로세스를 죽인다	멈춘다

느려지다가 죽는다 — 그 순서를 알아야 대응한다

스왑이 왜 그렇게 느린가

7강의 표를 보세요. 메모리 100ns, SSD 100,000ns.

1000배 — "조금 느려짐" 이 아니다

비유하자면 — 책상 위 책을 창고에 갖다 놓고 필요할 때마다 창고에 다녀오는 겁니다.

그리고 스래싱이 시작됩니다

메모리가 정말 모자라면 —

A 를 밀어내고 B 를 가져온다
A 가 필요해진다
B 를 밀어내고 A 를 가져온다
B 가 필요해진다…

일은 안 하고 옮기기만 한다 — 스래싱

이때 서버는 살아 있는데 응답이 없습니다. ssh 접속도 안 되죠. 가장 다루기 어려운 상태예요.

그래서 죽는 게 낫다는 판단이 나온다 — OOM Killer

먼저 `free`를 제대로 읽는 법

초보 관리자가 가장 많이 하는 오해가 여기 있습니다. "free가 300MB밖에 안 남았어요! 큰일이에요!"

고등학생free 를 제대로 읽는 법

15강에서 예고한 가장 흔한 오해를 정리합시다.

free 열이 아니라 available 열을 본다

free -h 의 열들

열	뜻
total	전체
used	프로그램이 쓰는 것
free	아무도 안 쓰는 것 ⚠
buff/cache	캐시로 쓰는 것
available	지금 쓸 수 있는 것 ✔

available = free + 비울 수 있는 캐시

예시

열	값
total	16G
used	4G
free	0.5G — 무섭게 보인다
buff/cache	11.5G
available	11G — 여유롭다 ✔

free 0.5G 를 보고 놀라면 안 사도 될 메모리를 산다

비유 — 주차장

주차장이 꽉 찼습니다. 자리가 없나요?

차	비울 수 있나
주인이 안에 있는 차	안 된다 (used)
임시 방문 차	즉시 뺀다 (캐시)

"꽉 찼다" 와 "자리가 없다" 는 다른 말이다

이 다섯 칸의 뜻을 정확히 알아야 합니다.

bash 브라우저에서 실행

free -h

칸	뜻	봐야 하나?
`total`	전체 메모리	기준값
`used`	프로세스들이 실제로 쓰는 양	△
`free`	아무도 안 쓰는 순수 빈 공간	✗ 보지 마세요
`buff/cache`	커널이 빌려 쓰고 있는 파일 캐시	△
`available`	새 프로그램이 당장 쓸 수 있는 양	✓ 이것만 보세요

고등학생남는 메모리는 낭비다 — 리눅스의 철학

note 의 이 문장이 리눅스 메모리 관리의 전부입니다.

비어 있는 메모리는 아무 일도 안 한다 — 그건 낭비다

그래서 무엇을 하나

남는 메모리에 읽었던 파일을 담아 둡니다. 다음에 같은 파일을 읽으면 디스크에 안 갑니다.

상황	파일 읽기
캐시에 있다	100ns
디스크에서	100,000ns

공짜로 1000배 를 얻는다 — 안 할 이유가 없다

그리고 필요하면 즉시 비웁니다

프로그램이 메모리를 달라고 하면 캐시를 버리고 줍니다. 기다림 없이요.

캐시는 있으면 이득, 없어도 손해 없음

비유 — 도서관 반납대

반납된 책을 바로 서가에 꽂지 않고 반납대에 잠깐 둡니다.

같은 책을 찾는 사람이 오면 바로 줄 수 있죠. 자리가 필요하면 그때 서가로 보냅니다.

공간이 남는데 미리 치울 이유가 없다

그래서 관리자가 하지 말아야 할 것

하지 말 것	왜
`echo 3 > drop_caches`	캐시를 버려서 느려진다
free 낮다고 증설	안 사도 된다
캐시를 "메모리 누수" 로 보고	엉뚱한 곳을 판다

캐시를 비우면 다시 채우느라 더 느려진다

워커 메모리를 계산합시다

쇼핑몰 서버에서 메모리를 먹는 건 대부분 gunicorn 워커입니다. 워커 하나가 얼마나 쓰는지 재고, 몇 개까지 띄울 수 있는지 계산해 봅시다.

RES 칸이 워커 하나가 실제로 잡은 물리 메모리입니다.

bash 브라우저에서 실행

# 워커의 실제 메모리(RES) 확인
ps aux | grep 'gunicorn: worker'
echo "=== 총합 ==="
top | head -6

워커 수의 상한은 CPU가 아니라 메모리가 정할 때가 많습니다.

Python 브라우저에서 실행

전체_MiB    = 16384
OS_예약     = 780      # 커널 + nginx + sshd + cron
안전_여유   = 0.12     # 12% 는 비워 둔다 (캐시·순간 급증용)
워커_MiB    = 340

쓸수있는 = 전체_MiB * (1 - 안전_여유) - OS_예약
최대워커 = int(쓸수있는 // 워커_MiB)

print(f"전체 메모리      : {전체_MiB:>7,} MiB")
print(f"OS·nginx 등      : {OS_예약:>7,} MiB")
print(f"안전 여유 {안전_여유*100:.0f}%    : {전체_MiB*안전_여유:>7,.0f} MiB")
print(f"워커에게 남는 양 : {쓸수있는:>7,.0f} MiB")
print(f"워커 하나        : {워커_MiB:>7,} MiB")
print("-" * 34)
print(f"→ 최대 워커 수   : {최대워커}개")
print()

for w in [4, 8, 13, 20, 48]:
    필요 = OS_예약 + w * 워커_MiB
    if 필요 > 전체_MiB:      상태 = "✗ OOM 위험"
    elif 필요 > 전체_MiB*0.88: 상태 = "△ 스왑 시작"
    else:                     상태 = "✓ 안전"
    print(f"워커 {w:>2}개 → {필요:>6,} MiB 필요 ({필요/전체_MiB*100:>5.1f}%)  {상태}")

메모리가 모자라면 벌어지는 일, 순서대로

파일 캐시를 버린다 — 조용히 일어남. 디스크 읽기가 조금 늘어난다
스왑으로 내린다 — 안 쓰는 페이지를 디스크로. 여기서부터 느려진다
스왑을 계속 들락날락(thrashing) — 응답시간이 무너진다. wa와 sy가 치솟는다
OOM Killer 발동 — 커널이 프로세스 하나를 죽인다

메모리를 14GB 요구하면 지표가 어떻게 되는지 봅니다.

bash 브라우저에서 실행

# 스왑에 빠진 서버는 어떻게 보이나 — 직접 만들어 봅시다
stress-ng --vm 1 --vm-bytes 14G --timeout 8s

si/so가 계속 0이 아니면 스왑 중입니다.

bash 브라우저에서 실행

# 지금 스왑 상태
free -h
cat /proc/swaps
echo "=== si/so 에 숫자가 찍히나 ==="
vmstat 1 3

고등학생OOM Killer 는 누구를 죽이나

note 의 이 대목이 운영에서 가장 아픈 순간을 설명합니다.

메모리가 정말 없으면 커널이 프로세스를 하나 죽인다

왜 죽이나

안 죽이면 전체가 멈춥니다. 스래싱으로 아무것도 못 하게 되죠.

하나를 죽여 나머지를 살리는 선택

누구를 고르나 — oom_score

기준	점수
메모리를 많이 쓴다	높다 ⚠
최근에 시작했다	조금 높다
root 프로세스	조금 낮다

대개 가장 큰 프로세스가 죽는다 — 보통 DB 나 앱

그래서 최악의 시나리오

메모리 누수로 워커가 붓는다
OOM Killer 가 DB 를 죽인다
범인은 살고 피해자가 죽는다

가장 큰 놈이 죽는다 ≠ 원인이 죽는다

비유 — 구명보트

보트가 가라앉습니다. 한 명을 내려야 해요. 누구를 내릴까요?

가장 무거운 사람을 내립니다. 그게 배에 구멍을 낸 사람은 아닐 수 있어요.

즉효는 있지만 원인은 남는다

관리자가 할 일

대비	방법
중요한 프로세스 보호	`oom_score_adj` 를 낮춘다
워커 메모리 제한	cgroup · `max-requests`
기록 남기기	`dmesg` 에 누가 죽었는지 남는다

사고 후 가장 먼저 볼 곳 — dmesg | grep -i oom

서버가 "이유 없이" 죽었다면 열에 아홉은 여기에 답이 있습니다.

실무에서 새벽 장애를 만나면 가장 먼저 치는 명령입니다.

bash 브라우저에서 실행

# OOM 이 났었는지 로그에서 확인
grep -i -E 'out of memory|oom' /var/log/syslog | tail -5

대응 방법 — 순서대로

방법	비용	언제
워커 수를 줄인다	무료·즉시	지금 당장 살려야 할 때. 처리량은 줄지만 죽지는 않는다
워커에 `max-requests` 를 건다	무료	메모리 누수가 의심될 때. 주기적으로 워커를 재시작
gunicorn `preload`	무료	워커들이 라이브러리를 공유하게 해 실사용량을 줄인다
메모리 증설	돈·재부팅	슬롯이 비어 있다면 가장 확실한 해법
코드에서 메모리 줄이기	시간	한 번에 다 읽지 말고 스트리밍으로
스왑을 늘린다	무료	근본 해결이 아니다. 죽는 대신 느려질 뿐

기본값 60은 데스크톱 기준입니다. 서버는 보통 10~20으로 낮춥니다.

bash 브라우저에서 실행

cat /proc/sys/vm/swappiness

🤔 확인 문제

free -h 결과가 total 16Gi, used 9.2Gi, free 0.3Gi, buff/cache 6.5Gi, available 6.8Gi 입니다. 이 서버는 위험한가요?

해설 free가 작은 건 커널이 남는 메모리를 파일 캐시로 잘 활용하고 있다는 뜻입니다. 프로그램이 메모리를 달라고 하면 캐시를 즉시 비워서 줍니다. 봐야 할 건 available이고, 6.8Gi = 42%면 여유롭습니다.

🤔 확인 문제

워커 하나가 340MiB를 쓰는 16GiB(16,384MiB) 서버에서, 워커를 48개로 늘리면 어떻게 될까요?

먼저 free를 제대로 읽는 법

워커 메모리를 계산합시다

메모리가 모자라면 벌어지는 일, 순서대로

대응 방법 — 순서대로

먼저 `free`를 제대로 읽는 법