High iowait can make a Linux system feel slow even when the CPUs are not saturated, because runnable work is left waiting for storage-related operations to finish before it can continue. Checking the wa field during the slowdown helps separate storage pressure from CPU-bound load when shells pause, jobs stall, or application response time suddenly stretches out.
Linux tracks CPU time in states such as user, system, idle, and I/O wait through /proc/stat, and tools such as vmstat and top turn those counters into interval-based percentages that are easier to read while a problem is happening. In both tools, the wa field is the part of the sample spent waiting for I/O completion rather than running normal work.
Kernel documentation warns that iowait is a symptom, not a precise per-device latency metric, especially on multicore systems where blocked tasks and idle CPUs are not a one-to-one match. Use it to confirm that storage wait is part of the slowdown, then correlate it with blocked tasks, device activity, or filesystem trouble before deciding what is actually slow. The first vmstat line is also an average since boot, so the later interval lines are the ones that matter during live troubleshooting.
Steps to check CPU I/O wait with vmstat and top in Linux:
- Sample CPU states over a few short intervals with vmstat.
$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu------- r b swpd free buff cache si so bi bo in cs us sy id wa st gu 3 0 0 15019628 883928 5493872 0 0 5 1365 523 0 2 1 98 0 0 0 2 0 0 14761400 883928 5753460 0 0 0 254776 3362 2278 5 12 80 3 0 0 1 1 0 14551256 883932 5965196 0 0 0 213620 2609 1734 5 9 82 4 0 0 2 0 0 14417592 883932 6200476 0 0 0 230052 4872 4480 9 11 77 3 0 0 4 0 0 14200672 883936 6410900 0 0 0 205404 5247 3927 20 7 68 4 0 0
The first data line is an average since boot. Read the later lines for the current interval and watch wa together with b, which shows tasks blocked in uninterruptible sleep and often rises when storage waits start stacking up.
- Capture a one-shot CPU summary with top in batch mode.
$ top -b -n 1 | head -n 5 top - 04:06:36 up 2 days, 14:39, 0 user, load average: 3.95, 5.22, 4.05 Tasks: 4 total, 2 running, 2 sleeping, 0 stopped, 0 zombie %Cpu(s): 33.1 us, 11.9 sy, 0.0 ni, 47.7 id, 6.6 wa, 0.0 hi, 0.7 si, 0.0 st MiB Mem : 23744.6 total, 13823.0 free, 3137.3 used, 7140.1 buff/cache MiB Swap: 1024.0 total, 1024.0 free, 0.0 used. 20607.4 avail Mem
top -b prints non-interactive output that is safe to use over SSH or in a log capture. The %Cpu(s) line is aggregated across CPUs, and wa is the share of the sample spent waiting for I/O completion.
- Repeat the vmstat sample across longer intervals while the slowdown is still happening.
$ vmstat 5 3 procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu------- r b swpd free buff cache si so bi bo in cs us sy id wa st gu 1 1 0 12815316 883952 7758144 0 0 5 1375 523 0 2 1 98 0 0 0 2 0 0 11765660 883956 8902544 0 0 0 222157 4024 3563 6 11 79 4 0 0 1 0 0 11130428 883960 9512744 0 0 0 134149 4794 4516 11 8 79 2 0 0
Short spikes during cache flushes or brief write bursts are common. Consistent non-zero wa across longer samples is a stronger sign that the system is repeatedly stalling on storage-related work.
- Correlate elevated wa with device-level activity before deciding where the bottleneck is.
High wa on its own does not identify the busy disk, virtual disk layer, network filesystem, or process behind the wait. Check block-device activity and per-task reads or writes during the same window to see where the storage delay is coming from.
Related: How to show disk activity on Linux
- Treat the result as a live indicator, not a historical verdict.
If the system feels slow but wa stays near zero during the same period, the bottleneck is more likely CPU saturation, memory reclaim, scheduler pressure, locking, or network delay than disk wait. If wa remains elevated and the b column grows, continue with storage and filesystem troubleshooting while the evidence is still visible.
Related: How to check disk errors in Linux
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
