Break Down a Report of "It's Slow"

목표

"서버가 느려요" 를 CPU · 메모리 · I/O 중 무엇인지로 쪼갭니다. 숫자를 직접 읽고, 누수인지 캐시인지를 기울기로 가릅니다.

왜 중요한가

느리다는 신고에 대한 가장 흔한 대응은 "사양을 올리자" 입니다. 그런데 D 상태 프로세스가 20개라 load 가 20인 기계에 CPU 를 늘리면 아무 일도 일어나지 않습니다. 증상과 원인을 잇는 숫자를 찾는 것이 이 실습의 전부입니다.

이 환경의 제약이 곧 훈련이다

이 파드는 커널 권한이 전부 제거돼 있어 perf·strace·bpftrace 를 쓸 수 없습니다. 대신 /proc 과 /sys/fs/cgroup 을 직접 읽습니다. 그건 저 도구들이 안에서 하는 일이고, 도구를 설치할 수 없는 고객사 서버에서 실제로 하게 되는 일이기도 합니다.

단계

1. 60초 분류 → /root/perf/01-triage.txt
2. /proc/stat 두 번 읽어 CPU 사용률 계산 → /root/perf/02-cpu.txt
3. CPU 1위 프로세스 → /root/perf/03-top.txt
4. RSS·PSS·Private_Dirty → /root/perf/04-mem.txt
5. 누수를 만들어 기울기로 확인 → /root/perf/05-slope.txt
6. cgroup 한도 → /root/perf/06-cgroup.txt
7. anon 과 file 분리 → /root/perf/07-split.txt
8. 결론 세 줄 → /root/perf/08-verdict.md

참고

• top 의 %CPU 가 100 을 넘어도 정상입니다 — 코어 하나 기준이라서입니다.
• free 에서 볼 값은 free 가 아니라 available 입니다.
• 여러 프로세스의 메모리를 합칠 때는 RSS 가 아니라 PSS 를 씁니다.

60초 분류

60초 분류 → /root/perf/01-triage.txt

/root/perf/01-triage.txt 에 네 줄을 적습니다. loadavg 세 숫자 / 프로세스 상태별 개수(R,D,S) / 코어 수 / available 메모리. 명령은 cat /proc/loadavg, ps -eo state --no-headers | sort | uniq -c, nproc, free -m. 무엇을 볼지 정하는 단계입니다.

CPU 사용률을 손으로 계산한다

/proc/stat 두 번 읽어 CPU 사용률 계산 → /root/perf/02-cpu.txt

/proc/stat 의 cpu 줄을 1초 간격으로 두 번 읽어 사용률을 구해 /root/perf/02-cpu.txt 에 숫자만 적으세요(0~100). busy=user+nice+system+irq+softirq+steal, idle=idle+iowait 입니다. top 이 하는 계산이 이것입니다.

누가 CPU 를 쓰는지 찾는다

CPU 1위 프로세스 → /root/perf/03-top.txt

ps -eo pid,pcpu,comm --sort=-pcpu | head 로 1위 프로세스의 이름을 /root/perf/03-top.txt 에 한 줄로 적습니다. 부하가 없으면 python3 -c 'while True: pass' & 로 하나 만들어 두고 보세요.

RSS·PSS·Private_Dirty 를 구분한다

RSS·PSS·Private_Dirty → /root/perf/04-mem.txt

아무 프로세스나 하나 골라 grep -E '^(Rss|Pss|Private_Dirty):' /proc/<PID>/smaps_rollup 결과를 /root/perf/04-mem.txt 에 그대로 저장하세요. 세 줄이 모두 있어야 합니다.

누수를 만들어 기울기로 잡는다

누수를 만들어 기울기로 확인 → /root/perf/05-slope.txt

일부러 새는 프로그램을 돌립니다. python3 -c "import time;L=[];\nwhile True: L.append(bytearray(1024*1024)); time.sleep(0.2)" & 같은 식입니다. 그 PID 의 Private_Dirty 를 5초 간격으로 4번 찍어 /root/perf/05-slope.txt 에 한 줄씩 저장하세요. 값이 단조 증가해야 합니다.

컨테이너의 진짜 한도를 본다

cgroup 한도 → /root/perf/06-cgroup.txt

/root/perf/06-cgroup.txt 에 memory.max, memory.current, cpu.max 세 값을 적습니다. cgroup v2 는 /sys/fs/cgroup/ 바로 아래에 있습니다. host 의 free 와 다른 숫자라는 것이 핵심입니다.

힙인가 캐시인가

anon 과 file 분리 → /root/perf/07-split.txt

grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat 를 /root/perf/07-split.txt 에 저장하세요. memory.current 가 한도에 닿아도 대부분이 file 이면 캐시라 회수 가능하고, anon 이면 진짜 압박입니다.

결론을 세 줄로

결론 세 줄 → /root/perf/08-verdict.md

/root/perf/08-verdict.md 에 세 줄. (1) 증상이 CPU 인가 메모리인가 I/O 인가 (2) 그렇게 판단한 근거가 된 숫자 (3) 다음에 확인할 것. 숫자 없는 결론은 추측입니다.