리눅스 CPU 100% 진단｜PID·스레드·iowait 20분 추적

서버가 느려졌을 때 top에서 CPU 100%만 보고 프로세스를 바로 종료하면 원인을 놓치기 쉽습니다. 실제 병목은 애플리케이션 연산, 커널 작업, 디스크 대기, 가상 서버의 CPU 경쟁 중 하나일 수 있습니다. 아래 순서는 현재 상태를 보존하면서 20분 안에 범위를 좁히는 방법입니다.

1. 3분: CPU 상태와 load average 구분

uptime
top -b -n 1 | head -n 20
nproc
cat /proc/pressure/cpu 2>/dev/null

load average는 CPU 사용률이 아닙니다. 실행 중이거나 실행을 기다리는 작업과 디스크 I/O 대기 상태의 작업을 1·5·15분 평균으로 보여줍니다. 따라서 load가 높아도 CPU가 한가하면 디스크나 스토리지부터 확인해야 합니다. 코어가 4개인 서버에서 load 4가 곧 장애라는 뜻도 아닙니다. 추세와 응답 지연을 함께 보세요.

2. 5분: CPU를 쓰는 PID 고정

ps -eo pid,ppid,user,stat,etime,pcpu,pmem,comm --sort=-pcpu | head -n 15
pidstat -u -r -d 1 5

ps는 한 시점의 사진이고 pidstat는 짧은 구간의 변화입니다. 두 결과에 계속 등장하는 PID를 우선 조사합니다. 순간적으로 튀었다가 사라지는 작업과 지속적으로 코어를 점유하는 작업을 구분할 수 있습니다. pidstat가 없다면 sysstat 패키지 설치 가능 여부를 먼저 확인하세요.

3. 5분: 프로세스 안의 스레드 추적

top -H -p PID
ps -L -p PID -o pid,tid,psr,pcpu,stat,comm --sort=-pcpu

웹 서버·자바·데이터베이스처럼 스레드를 많이 쓰는 프로그램은 프로세스 이름만으로 부족합니다. top -H는 개별 스레드를 표시하고, ps -L은 TID와 실행 CPU를 함께 남길 수 있습니다. 같은 TID가 반복해서 높다면 그 시각의 애플리케이션 로그, 느린 쿼리, 배치 실행 기록을 연결해 봅니다.

4. 컨테이너와 I/O 대기 분리

docker stats --no-stream
cat /proc/pressure/io 2>/dev/null
cat /proc/pressure/memory 2>/dev/null

Docker 환경이라면 호스트 PID만 보지 말고 컨테이너별 CPU·메모리·Block I/O·PIDs를 먼저 비교합니다. Linux PSI의 some은 일부 작업이 자원 때문에 멈춘 시간, full은 비유휴 작업 전체가 동시에 멈춘 시간을 뜻합니다. CPU는 낮은데 I/O pressure가 계속 높다면 애플리케이션 최적화보다 디스크·DB 경로가 우선입니다.

5. 7분: 변경 시각과 원복 기준 기록

• CPU 상승 시작 시각과 배포·플러그인·배치 변경 시각을 비교합니다.
• PID, TID, CPU 상태, PSI와 관련 로그를 한 묶음으로 저장합니다.
• 동시에 여러 설정을 바꾸지 말고 한 번에 하나만 조정합니다.
• CPU와 응답 시간이 개선되지 않으면 즉시 이전 설정으로 원복합니다.
• 서비스 재시작이 필요하면 사용자 영향과 정상 종료 절차를 먼저 확인합니다.

TIP

장애 순간의 한 장면보다 1초 간격 5회처럼 짧은 연속 측정이 더 유용합니다. ‘몇 시에, 어떤 PID와 TID가, 어떤 CPU 상태와 함께 올랐는지’를 남기면 재발 때 비교 기준이 됩니다. 서버 응답이 느리다면 HTTP/2·HTTP/3 적용 확인, 전송량이 크다면 Gzip·Brotli 압축 진단도 함께 확인하세요.

마무리

리눅스 CPU 100% 진단은 ‘높은 프로세스 찾기’에서 끝나지 않습니다. CPU 상태를 분류하고, PID에서 스레드로 좁힌 뒤, 컨테이너·PSI·로그와 변경 이력을 연결해야 재발 방지까지 이어집니다. 강제 종료 전에는 반드시 원인 자료와 원복 경로를 남기세요.

공식 참고 자료

• Linux top 매뉴얼
• Linux /proc/loadavg 매뉴얼
• sysstat 공식 저장소
• Linux 커널 PSI 문서
• Docker stats 공식 문서