Linux Performance Engineering
느린 PostgreSQL을 만났을 때 SQL만 들여다보면 원인을 놓치기 쉽습니다. CPU run queue, memory reclaim, storage latency, TCP retransmission처럼 database 바깥의 자원 경합이 같은 증상을 만들기 때문입니다. 이 노트는 Linux에서 증상 → 자원 → 포화 지점 → 원인 process 순서로 범위를 좁히는 방법을 다룹니다.
명령을 외우기보다 질문을 먼저 정합니다. 무엇이 바쁜지, 얼마나 기다리는지, 어느 workload가 자원을 쓰는지, 변화가 언제 시작됐는지를 증거로 답하는 것이 목표입니다.
차례
- Part I. 성능 분석의 기준: workload, baseline, USE 방법론
- Part II. CPU와 Scheduler: utilization, run queue, context switch, cgroup
- Part III. Memory: virtual memory, page cache, reclaim, OOM
- Part IV. Storage와 I/O: latency, queue, filesystem, PostgreSQL write path
- Part V. Network: TCP, socket queue, retransmission, DNS
- Part VI. 도구와 장애 분석: procfs, perf, eBPF, node_exporter, incident workflow
권장 학습 방식
각 장의 명령은 한 번의 숫자로 결론 내리지 않습니다. 정상 시간대와 문제 시간대의 출력, host 전체와 process 단위 출력, PostgreSQL metric을 같은 시간축에 놓고 비교합니다. 운영 환경에서는 perf, eBPF, 부하 생성 도구의 권한과 overhead를 먼저 검토합니다.
다운로드 가능한 read-only 진단 스크립트는 변경 명령 없이 기본 상태를 모읍니다.