Blog

“서버가 느려요”라는 신고가 들어오면 vmstat, top, iostat을 순서 없이 아무거나 띄워보다가 우연히 눈에 띈 수치에 매달리기 쉽다. Brendan Gregg가 정리한 USE Method(Utilization / Saturation / Errors)는 이런 무작위 삽질 대신, 시스템의 모든 리소스(CPU/메모리/디스크/네트워크)를 세 가지 관점으로 빠짐없이 훑어 병목 후보를 좁히는 체크리스트다. 이 글에서는 USE Method의 개념과, 실제 리눅스 명령어로 U/S/E 세 값을 확인하는 방법을 정리한다.

USE Method란

• Utilization — 리소스가 작업 처리에 사용된 시간의 비율 (예: CPU %usr+%sys)
• Saturation — 리소스가 처리할 수 있는 양보다 더 많은 작업이 대기 중인 정도 (큐 길이, 대기 시간)
• Errors — 리소스에서 발생한 에러 이벤트 수 (재시도, 드롭, 커널 로그 등)

핵심은 Utilization만 보고 끝내지 않는 것이다. CPU 사용률이 60%라도 특정 코어에 작업이 몰려 대기 큐가 쌓이고 있으면 이미 saturation 상태다.

리소스별 체크리스트

실전 진단 — CPU Saturation 재현

6코어 Ubuntu 24.04 호스트에서 코어 수보다 많은 12개 프로세스를 동시에 돌려 CPU를 의도적으로 포화시킨다.

nproc   # 6
for i in $(seq 1 12); do yes > /dev/null & done
vmstat 1 4
uptime

# 평상시
 r  b   ...  us sy id wa
 1  0   ...   0  1 97  2

# 부하 상태 (yes 12개 실행 중)
 r  b   ...  us sy id wa
13  2   ...   0  1 97  2
13  0   ...  25 75  0  0
15  0   ...  29 71  0  0
12  0   ...   0 100  0  0

load average: 0.00, 0.02, 0.17  →  1.62, 0.37, 0.28 (1분 평균)

코어는 6개인데 r(run queue) 컬럼이 12~15로 뛴다 — CPU %usr+%sys(Utilization)는 100%를 넘길 수 없어 둔감하지만, 코어 수를 넘는 run queue와 load average는 saturation을 직접 보여준다. 커널이 /proc/pressure/cpu로 이 saturation을 수치화한 PSI(Pressure Stall Information) 값도 함께 확인할 수 있다.

cat /proc/pressure/cpu
cat /proc/pressure/memory

# cpu (부하 직후, avg60에 여전히 반영되어 있음)
some avg10=3.12 avg60=11.05 avg300=3.97 total=47279140

# memory (부하가 CPU에만 몰렸으므로 압력 없음)
some avg10=0.00 avg60=0.00 avg300=0.00 total=0

avg10보다 avg60이 더 높게 남아있는 건 순간적 부하가 60초 이동평균에는 아직 반영 중이라는 뜻이다. 반면 메모리 PSI는 0이므로 이번 부하는 CPU에만 국한된 것을 바로 구분할 수 있다 — vmstat 여러 컬럼을 눈으로 대조하지 않아도 PSI 한 줄이 saturation 여부를 알려준다.

네트워크 Errors 확인

ip -s link show

2: enp0s3: ...
    RX: bytes packets errors dropped missed mcast
        249831   1071      0       0      0    451
    TX: bytes packets errors dropped carrier collsns
        161675    703      0       0      0       0

3: docker0: ...
    TX: bytes packets errors dropped carrier collsns
            0      0      0      37      0       0

실제 트래픽이 오가는 enp0s3은 errors/dropped 모두 0으로 깨끗하지만, 캐리어가 없는 docker0은 TX dropped가 37건 쌓여 있다 — 인터페이스가 죽어있거나 케이블이 빠진 상태를 errors 컬럼만으로 바로 알 수 있는 사례다.

주의사항

• PSI(/proc/pressure/*)는 리눅스 4.20 이상, CONFIG_PSI=y로 빌드된 커널에서만 존재한다 — 오래된 배포판/임베디드 커널은 지원하지 않을 수 있다
• USE Method는 단일 호스트의 하드웨어 리소스 진단용 체크리스트다. 여러 서비스가 얽힌 분산 시스템의 지연시간 문제는 이 방법만으로 좁혀지지 않고, 별도의 요청 단위 트레이싱이 필요하다
• Utilization 100%가 항상 문제는 아니다 — 배치 작업처럼 의도적으로 리소스를 끝까지 쓰는 워크로드도 있으므로, saturation·errors와 함께 봐야 진짜 병목인지 판단할 수 있다

마무리

USE Method의 실익은 새로운 도구를 배우는 데 있지 않고, CPU/메모리/디스크/네트워크 네 가지 리소스를 U/S/E 순서로 빠짐없이 훑는 습관에 있다. 특히 Saturation은 Utilization보다 놓치기 쉬운데, PSI 같은 커널 내장 지표를 활용하면 vmstat·mpstat 여러 컬럼을 직접 대조하지 않고도 대기 상태를 바로 확인할 수 있다.

참고

• The USE Method — Brendan Gregg
• Pressure Stall Information (PSI) — The Linux Kernel documentation