A server's load average shows 8.0 on a 4-core machine, but CPU usage in top only shows 20%. How can load be double the core count while CPU usage looks low?

Linux's load average counts processes in an uninterruptible sleep state (typically D state, usually waiting on I/O) as contributing to load, not just processes actively running on or waiting for CPU time — a high load average with low CPU usage almost always means many processes are blocked waiting on something other than CPU, most commonly disk I/O, meaning the actual bottleneck is I/O throughput or latency, not CPU capacity.

Load average is frequently misunderstood as purely a CPU-demand metric, but Linux's actual definition includes both processes waiting for CPU time and processes in uninterruptible sleep (D state) — a state a process enters when it's blocked on a low-level I/O operation (disk reads/writes, certain network filesystem calls) that can't be interrupted by a signal until it completes.

Load average reflects total "wanting to run but blocked" demand, not just CPU contention: the classic Unix definition counts the number of processes in the run queue (waiting for CPU) plus processes in uninterruptible sleep (waiting on I/O) — CPU usage percentage, by contrast, only measures how busy the CPU itself actually is doing work, which is a genuinely different, narrower thing.

A high load average with low CPU usage points specifically at I/O bottlenecks: if many processes are blocked in D state waiting on slow or overwhelmed disk I/O, they contribute to load average significantly while the CPU itself sits mostly idle, since the CPU has nothing to actually execute for those blocked processes — it's not that the system isn't under stress, it's that the stress is on the I/O subsystem, not the CPU, and CPU usage alone gives no visibility into that.

Confirming the diagnosis requires looking beyond both metrics individually: vmstat or iostat showing high I/O wait time (wa in top's CPU line, or the equivalent in vmstat), and specifically checking for processes in D state (ps aux | awk '$8 ~ /D/'), confirms the hypothesis directly rather than inferring it purely from the load-average/CPU-usage mismatch.

This is a common, genuinely useful diagnostic signature: "high load, low CPU" is specifically the signature of an I/O-bound bottleneck (disk saturation, a slow or overwhelmed storage backend, excessive swapping) — distinct from "high load, high CPU" (genuine CPU saturation) which points toward entirely different remediation (more CPU capacity, more efficient code) than an I/O bottleneck would (faster storage, reducing I/O volume, addressing a specific slow disk or storage backend).

The "load average exceeds core count" heuristic still applies, but needs the right interpretation: a load average meaningfully above the core count does indicate the system has more demand than it can immediately service — the diagnostic question is just what kind of demand (CPU-bound or I/O-bound), which requires looking at CPU usage and I/O wait together, not either metric in isolation.

• Linux load average counts both CPU-queue-waiting processes and I/O-blocked processes (uninterruptible sleep, D state) — it's not a pure CPU-demand metric.
• High load average combined with low CPU usage is the classic signature of an I/O bottleneck, not a CPU bottleneck — the CPU is idle because processes are blocked waiting on I/O, not because there's no demand.
• Confirm the diagnosis with iostat/vmstat (I/O wait time) and by checking for processes actually in D state, rather than inferring purely from the load/CPU mismatch.
• The remediation differs entirely depending on which kind of bottleneck it is — more CPU capacity doesn't help an I/O-bound problem, and faster storage doesn't help a genuinely CPU-bound one.

• Linux man-pages: uptime(1)
• Linux Load Averages: Solving the Mystery (Brendan Gregg)