OS 관점의 성능 병목 분석
3줄 요약
- OS 관점 병목 분석은 CPU, memory, disk I/O, network, thread, pool을 같은 시간축에서 구분하는 작업이다.
- CPU bound, memory pressure, iowait, pool 고갈은 증상이 비슷해도 완화와 근본 수정이 다르다.
- 성능 장애 대응은 지표 확보, 원인 후보 제거, 임시 완화, 재발 방지 순서로 진행한다.
핵심 정리
- CPU bound는 runnable 작업이 많고 core가 포화되어 계산 처리량이 한계에 닿은 상태다.
- Load average는 실행 중이거나 uninterruptible I/O 대기 중인 작업까지 포함하므로 CPU 사용률과 함께 봐야 한다.
- Memory pressure는 GC 증가, RSS 상승, page fault, swap, OOM kill로 드러날 수 있다.
- I/O wait와 disk latency는 로그, dump, DB, 파일 업로드, swap과 연결될 수 있다.
- Thread pool과 connection pool 병목은 OS 자원 병목의 결과일 수도 있고 원인일 수도 있다.
헷갈리는 지점
- Load average가 높으면 항상 CPU 문제라고 보기 쉽다.
- Uninterruptible I/O 대기도 load average에 포함될 수 있다.
- CPU 사용률, iowait, runnable thread를 함께 봐야 한다.
- Memory를 늘리면 메모리 문제가 해결된다고 단정하기 쉽다.
- Leak이나 unbounded cache는 memory를 늘려도 재발한다.
- 증상 완화와 코드/정책 수정은 분리해야 한다.
- Pool 크기를 늘리면 병목이 풀린다고 생각하기 쉽다.
- 하위 자원이 병목이면 동시성을 늘리는 것이 장애를 증폭할 수 있다.
- 대기 원인과 하위 capacity를 먼저 본다.
확인 질문
- CPU bound와 I/O wait를 구분하려면 무엇을 봐야 하는가?
- CPU 사용률, runnable thread, iowait, disk latency, thread stack을 함께 봐야 한다.
- Pool 고갈이 원인인지 결과인지 확인하려면 무엇이 필요한가?
- Pool active/pending, 하위 시스템 latency, lock/I/O 대기, 최근 트래픽과 배포 이력이 필요하다.
- 성능 장애 원인 격리의 핵심은 무엇인가?
- 같은 시간축에서 지표를 맞추고 원인 후보를 하나씩 제거하는 것이다.