It's Not Just CPU
When you run top or uptime, you see three numbers labeled "load average" — something like 0.52, 1.20, 2.87.
These represent the average number of processes in a demanding state over the last 1 minute, 5 minutes, and 15 minutes respectively. Most engineers assume this measures CPU usage. It does not.
Linux Load Average = processes in R state + processes in D state
It counts every process that is either actively running/runnable (wants CPU) or stuck in uninterruptible sleep (wants I/O). Both types of processes are "demanding" something from the system.
Why this distinction matters enormously:
On a 4-core machine, a load average of 4.0 means the system is exactly saturated — 4 processes demanding resources, 4 cores available. But which resources are being demanded?
- Load 4.0, CPU usage 95% → CPU-bound. Add more cores or optimize code.
- Load 4.0, CPU usage 5% → I/O-bound. Everything is stuck waiting for disk or network. Adding CPUs won't help at all.
Telling the two apart means cross-referencing the load number against actual CPU utilization, then counting how many processes are sitting in D-state versus R-state and checking disk I/O saturation directly — the load figure alone (from uptime or /proc/loadavg) never tells you which resource is actually under pressure.
A common war story: an engineer sees load average of 40 on a 16-core machine, panics, and upgrades to a 32-core instance. Load average stays at 40. The problem was a failing NFS mount keeping 40 processes in D-state — CPU was irrelevant.