9강 / 20강

메모리 — 좁은 책상을 나눠 쓰기

가상 메모리, 스왑, 그리고 서버가 죽는 이유

비유 하나로 시작합시다.

🪑

책상 (RAM)

좁지만 아주 빠름. 지금 보는 책만 올려 둠

📚

책장 (디스크)

넓지만 느림. 안 보는 책은 여기

🧑‍💼

사서 (OS)

필요한 책을 꺼내 오고 안 쓰는 건 꽂아 둠

메모리(RAM)는 디스크보다 수백 배 빠릅니다. 대신 훨씬 좁고 비싸요. 그래서 프로그램은 지금 필요한 부분만 메모리에 올려 두고 씁니다.

고등학생좁은 책상을 나눠 쓰기

메모리는 가장 부족한 자원입니다.

CPU 는 나눠 쓰면 되는데 메모리는 동시에 필요하다

차이가 뭔가

자원	나누는 법
CPU	시간으로 나눈다 — 번갈아
메모리	공간으로 나눈다 — 동시에

CPU 는 기다리면 되지만 메모리는 모자라면 끝이다

비유 — 책상과 시계

	비유
CPU	시계 — 순서대로 쓰면 된다
메모리	책상 — 자리가 없으면 못 편다

공부할 사람이 많으면 순서대로 하면 됩니다. 그런데 책상이 좁으면 펼 수가 없어요.

그래서 메모리 부족이 더 치명적이다

운영체제가 하는 세 가지

기술	하는 일
가상 메모리	각자에게 넓은 척 해 준다
스왑	안 쓰는 것을 디스크로
OOM Killer	정말 없으면 하나를 죽인다

세 번째까지 가면 이미 늦은 것이다

이 서버의 책상이 얼마나 넓고, 얼마나 찼는지

bash 내 가상 Ubuntu 서버에서 실행

free -h

total전체 메모리이 서버는 약 2GB

used지금 쓰는 중프로세스들이 차지한 양

buff/cache미리 읽어 둔 것필요하면 즉시 내줄 수 있음

available진짜 여유이 숫자를 보세요

Swap디스크를 메모리처럼모자랄 때 쓰는 비상 공간

고등학생free 를 처음 보면 다들 놀랍니다

note 의 이 말이 맞습니다. free 가 거의 0 이거든요.

놀라지 마세요 — 정상입니다

열을 제대로 읽어야 합니다

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

available 을 본다 — free 가 아니라

왜 캐시가 메모리를 다 차지하나

리눅스의 철학입니다 —

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

남는 메모리에 읽었던 파일을 담아 둡니다. 다시 읽으면 디스크에 안 가도 되죠.

읽는 곳	속도
캐시 (메모리)	수백 배 빠르다
디스크	느리다

그리고 필요하면 즉시 비워 준다 — 손해가 없다

비유 — 도서관 반납대

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

같은 책을 찾는 사람이 오면 바로 줄 수 있고, 자리가 필요하면 그때 치웁니다.

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

하지 말아야 할 것

하지 말 것	왜
`drop_caches`	캐시를 버려서 느려진다
free 낮다고 증설	안 사도 된다

가상 메모리 — 모두에게 "전부 네 것"이라고 속이기

여기서 운영체제의 가장 우아한 속임수가 등장합니다.

프로세스 A와 B가 둘 다 "내 메모리 0번지"에 값을 씁니다. 충돌할까요? 안 합니다. 두 프로세스가 말하는 0번지는 서로 다른 진짜 위치이기 때문입니다.

각 프로세스는 자기만의 가상 주소를 갖고, 커널이 그것을 진짜 주소로 몰래 바꿔 줍니다. 이걸 가상 메모리(virtual memory)라고 해요.

가상 메모리 덕분에

A의 0번지 → 진짜 4096번지
B의 0번지 → 진짜 8192번지

서로의 메모리를 볼 수도 없습니다

만약 없었다면

A가 B의 비밀번호를
메모리에서 그냥 읽음

앱 하나가 터지면 전체가 터짐

🎮 메모리 실험실

프로세스를 만들어 메모리를 채워 보세요. 가득 차면 무슨 일이 벌어지는지, 스왑이 어떻게 버텨 주는지, 그러다 결국 OOM Killer 가 등장하는 장면까지 볼 수 있습니다.

고등학생OOM Killer — 커널의 냉정한 선택

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

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

왜 죽이나

안 죽이면 전체가 멈춥니다. 스왑을 오가느라 아무것도 못 하게 되죠.

선택	결과
가만둔다	전부 멈춘다 — ssh 도 안 된다
하나를 죽인다	나머지가 산다

최악을 피하려 차악을 고른다

누구를 고르나

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

대개 가장 큰 것이 죽는다 — 보통 DB 나 앱

그래서 최악의 시나리오

어떤 프로그램이 메모리를 샌다
메모리가 찬다
OOM Killer 가 DB 를 죽인다
범인은 살고 피해자가 죽는다

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

비유 — 구명보트

보트가 가라앉습니다. 한 명을 내려야 해요. 가장 무거운 사람을 내리죠.

그런데 그 사람이 보트에 구멍을 낸 사람은 아닐 수 있습니다.

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

사고 후 가장 먼저 볼 것

dmesg | grep -i "killed process"
journalctl -k | grep -i oom

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

18강의 장애 대응에서 이 명령을 다시 씁니다.

스왑 — 책상이 좁으면 바닥에 쌓기

메모리가 모자라면 커널은 당장 안 쓰는 부분을 디스크로 옮깁니다. 이 공간이 스왑(swap)이에요. 덕분에 서버가 바로 죽지는 않습니다.

대신 엄청나게 느려집니다. 디스크는 메모리보다 수백 배 느리니까요. "서버가 안 죽었는데 응답이 30초씩 걸린다"면 스왑을 의심해야 합니다.

/proc 은 커널이 실시간으로 만들어 주는 가짜 파일들입니다

bash 내 가상 Ubuntu 서버에서 실행

free -h
cat /proc/meminfo | head -8

고등학생/proc 은 디스크에 없는 파일입니다

note 의 이 설명이 4강의 철학과 이어집니다.

/proc 은 커널이 만들어 보여 주는 가짜 파일 시스템

읽을 때마다 새로 만듭니다

파일	보여 주는 것
`/proc/meminfo`	지금 메모리 상태
`/proc/loadavg`	지금 부하
`/proc/uptime`	켜진 지 얼마나
`/proc/1234/status`	PID 1234 의 상태

디스크 용량을 차지하지 않는다 — 파일이 아니니까

왜 이렇게 만들었나

4강의 "모든 것은 파일이다" 철학 때문입니다.

방식	필요한 것
전용 API	프로그램마다 따로 배워야
파일로	cat · grep 이면 끝 ✔

이미 아는 도구로 새로운 것을 다룬다

비유 — 실시간 전광판

기차역 전광판에는 지금 시각이 나옵니다. 그 숫자가 어딘가에 저장돼 있나요?

아니죠. 볼 때마다 계산해서 보여 줍니다.

/proc 이 그렇다 — 저장된 게 아니라 계산된 값

쓸 수도 있습니다

cat /proc/sys/vm/swappiness       # 읽기
echo 10 > /proc/sys/vm/swappiness  # 쓰기 — 설정 변경!

설정	뜻
swappiness 60	기본 — 적극적으로 스왑
swappiness 10	서버 권장 — 되도록 안 스왑

파일에 쓰는 것이 곧 설정 변경이다 — 재부팅하면 사라진다

영구히 하려면 /etc/sysctl.conf 에 적습니다.

🤔 확인 문제

free -h 결과에서 서버에 메모리 여유가 있는지 판단할 때 봐야 할 숫자는?

해설 리눅스는 남는 메모리를 캐시로 알뜰히 씁니다. 그래서 free 는 항상 작아 보여요. 캐시는 필요하면 즉시 반환되므로, 진짜 여유는 available 입니다.

🤔 확인 문제

가상 메모리가 없다면 생길 문제로 가장 알맞은 것은?

🤔 확인 문제

서버가 죽지는 않았는데 응답이 몇십 초씩 걸린다면 가장 먼저 의심할 것은?

해설 스왑은 디스크를 메모리처럼 쓰는 비상 수단이라 수백 배 느립니다. free -h 에서 Swap used 가 크다면 거의 확실합니다. 메모리를 늘리거나, 범인 프로세스를 찾아야 합니다.