I/O Wait(iowait)란? CPU는 놀고 있는데 서버가 느릴 수 있는 이유 쉽게 이해하기

`user`·`system`·`idle` 옆에 iowait 50%가 보이면 「CPU가 Disk 때문에 절반 멈췄다」로 읽기 쉽습니다. I/O 관련 대기를 의심하는 방향은 맞지만, iowait = CPU가 Disk에 붙잡혀 멈춘 시간으로만 보면 정확하지 않습니다. Linux에서 iowait는 CPU가 Idle이면서 아직 완료되지 않은 I/O가 있는 상황과 관련된 시간 분류입니다. 당장 실행할 Runnable은 없는데 Storage 등이 끝나기를 기다리는 작업이 있을 때 나타나는 단서에 가깝습니다. CPU Utilization의 한 조각입니다.

요리사: 반죽 끝 → 오븐 30분
다른 주문 없음 → 요리사 대기 · 오븐은 작업 중
CPU ↔ Storage도 같은 분리

CPU와 Storage는 다른 장치

Application이 파일을 읽으면 Kernel을 거쳐 Storage가 준비합니다. 그동안 다른 Runnable이 있으면 CPU는 B·C·D를 돌립니다 — I/O 하나가 기다린다고 그 시간 전체가 iowait로 잡히지 않습니다. Runnable이 없고 I/O만 남으면 CPU Idle + 미완료 I/O → iowait 분류와 연결됩니다. 운영 관점의 신호는 「CPU가 놀 때 미완료 I/O가 있었다」이지, 「Disk가 확실히 고장」이 아닙니다. Latency·IOPS·Throughput·I/O Queue·어느 Process가 I/O를 만드는지까지 봅니다. SSD가 빨라도 Workload가 Capacity를 넘으면 Queue가 쌓입니다. 「느린 Disk」가 아니라 「요청이 너무 많음」일 수도 있습니다. Load Average가 높고 CPU는 낮을 때도 같은 축을 의심합니다.

Latency · IOPS · Throughput · Queue

IOPS는 초당 읽기·쓰기 Operation 수, Throughput은 MB/s·GB/s 데이터량입니다. 작은 Random 4KB는 IOPS가, 큰 순차 파일은 Throughput이 더 중요할 수 있습니다. Latency는 한 요청 완료까지 시간입니다. Queue가 길면 Waiting이 늘고 Application·HTTP까지 늦어집니다 — Queueing Theory·Arrival > Service Rate와 같습니다. Network Storage면 Network Congestion도 I/O로 보일 수 있습니다.

Disk Saturation · 느린 HDD Random · NFS/Cloud Disk
DB Cache Miss · Swap/Thrashing · Backup·Log Write 경쟁
→ 같은 시각 Spike면 Cron/Backup 먼저

흔한 원인 · 잘못된 Scale Up

DB Working Set이 RAM보다 크면 Disk Read가 늘고, Swap Thrashing이면 Paging I/O가 폭증할 수 있습니다. Backup·로그 폭주·동기 Write·자주 하는 fsync/WAL Flush도 Commit Latency를 키웁니다(로그). Cloud Disk는 Provisioned IOPS·Burst Credit 소진 후 급락할 수 있습니다. iowait 높음 → CPU만 늘리기는 위험합니다. Worker가 늘면 Query·I/O가 더 늘어 Storage를 더 포화시킬 수 있습니다(Auto Scaling·Bottleneck Shift·Contention). 반대로 iowait가 낮아도 CPU가 항상 Busy면 느린 I/O가 가려질 수 있습니다. Process별 Wait ≠ CPU iowait 1:1. Async I/O는 Thread를 아끼지 Storage Latency를 없애지 않습니다 — Concurrency만 키우면 Queue가 더 커질 수 있어 Backpressure·동시 I/O 제한이 필요합니다.

조사 흐름 · 완화

느림 → CPU 낮음 + iowait 높음 → Latency/Queue/IOPS·Throughput Limit → Process(DB·Backup·Log) → 원인별 대응(시간 분산·Index/Cache·Storage 업그레이드·RAM·I/O Limit). Upload·썸네일·Backup을 같은 Disk에 몰지 말고 Object Storage·Worker·Storage 분리, Memory Cache·CDN·DB Buffer Pool로 Disk 접근을 줄입니다. μs 단위 CPU 미세 최적화보다 500ms Disk Wait가 우선입니다. 분산 추적·Slow Query와 Disk Latency 동시 Spike를 봅니다. SEO 전용 지표는 아니지만 Timeout·5xx가 늘면 UX에 간접 영향(모니터링·503).

정리

iowait = CPU Idle + 미완료 I/O가 있던 상황과 관련된 분류입니다. 「I/O 하나가 몇 초 기다렸나」를 직접 찍는 지표가 아닙니다. 높음 ≠ CPU 문제, 높음 ≠ Disk 고장 — Latency·IOPS·Throughput·Queue·Process·Swap을 함께 봅니다. Throughput만 충분해 보여도 작은 Random Read가 수만 개면 초당 Operation 수 한계에 먼저 닿을 수 있습니다. 이처럼 Storage가 1초 동안 몇 번의 읽기·쓰기를 처리할 수 있는지를 나타내는 지표가 IOPS(Input/Output Operations Per Second)입니다.