[Linux 성능 분석] Day 1: 측정 모델 - 느리다는 말을 증거로 바꾸기
이 글은 AI(Claude)의 도움을 받아 작성하고, 작성자가 검토·편집했습니다.
서론: 오늘의 문제
성능 문제는 CPU가 높다는 한 문장으로 설명되지 않는다. 사용자 증상과 자원 포화, 오류, 대기 시간을 연결하고 정상 기준선과 비교하는 조사 순서를 만든다.
1. 사용자 증상 고정
어떤 요청이 언제부터 얼마나 느려졌는지 p50, p95, p99와 오류율로 범위를 정한다. 시스템 전체 평균보다 영향을 받은 endpoint, tenant, region을 먼저 분리한다.
2. Utilization과 Saturation
자원 사용률이 높지 않아도 대기열이 길면 포화 상태일 수 있다. CPU run queue, 메모리 reclaim, 디스크 await처럼 자원별 대기 신호를 사용률과 함께 본다.
3. 오류와 재시도
timeout, drop, OOM, 재전송은 성능 저하의 결과이자 추가 부하의 원인이다. 애플리케이션 재시도량을 원래 요청량과 분리해 증폭 계수를 계산한다.
4. 기준선과 변화점
정상 시간대의 동일 트래픽 수준과 비교하고 배포, 커널, 인스턴스 타입, 데이터 크기 변화를 타임라인에 겹친다. 절대 임계값만으로 계절성과 피크를 오판하지 않는다.
5. 가설을 좁히는 순서
서비스 지연에서 호스트, 프로세스, 스레드, 함수로 점차 범위를 좁힌다. 도구를 무작위로 실행하기보다 각 관측이 어떤 가설을 반증하는지 기록한다.
6. 자주 실패하는 방식
장애 중 곧바로 튜닝 값을 바꾸면 원인 증거와 비교 기준을 잃는다. CPU 사용률 하나로 결론 내리면 I/O 대기와 lock contention, 외부 의존성 지연을 놓친다.
7. 관측과 검증
서비스 지연과 처리량, CPU run queue, PSI, major fault, disk await, 네트워크 retransmit을 동일 시간축으로 정렬한다. 기준값은 정상 시간대와 변경 전후를 비교해 정하고, 점검 결과가 실제 행동으로 이어지는지 정기적으로 확인한다.
실행 흐름
1
2
3
4
5
6
7
8
9
1. 사용자 증상 고정
↓
2. Utilization과 Saturation
↓
3. 오류와 재시도
↓
4. 기준선과 변화점
↓
5. 가설을 좁히는 순서
개별 도구보다 이 순서를 팀의 설계 리뷰와 Runbook에 남기는 것이 중요하다. 상황이 달라져도 판단 근거와 검증 결과가 이어져야 한다.
실전 체크리스트
- 사용자 증상 고정: 기준과 책임자를 문서화했다.
- Utilization과 Saturation: 기준과 책임자를 문서화했다.
- 오류와 재시도: 기준과 책임자를 문서화했다.
- 기준선과 변화점: 기준과 책임자를 문서화했다.
- 가설을 좁히는 순서: 기준과 책임자를 문서화했다.
- 실패 패턴을 재현하고 안전한 복구 경로를 확인했다.
- 핵심 신호를 대시보드와 변경 검증에 연결했다.
참고 자료
다음 글
다음 글에서는 CPU와 스케줄링 - 사용률 뒤의 대기열 읽기를 다룬다.