What Load Average Actually Is — and How It Differs from CPU Usage

Infrastructure Linux Performance
4 min read

The three numbers uptime prints — load average — are the most famous and most misread metric in Linux. Half-true folklore abounds: “over 1.0 is dangerous,” “it’s basically CPU usage.” This post pins down the exact definition and the classic cases where it diverges from CPU utilization. Hardware Intermediate #1 covered the metric landscape; here we dig into this one number all the way.

uptime 
$ uptime
 14:32:07 up 213 days,  4:11,  1 user,  load average: 6.12, 4.35, 2.08

The definition — running + runnable + disk wait #

Linux’s load average is an exponential moving average of the count of:

  • Running (R): tasks on a CPU core right now
  • Runnable (R): tasks ready to run, waiting for a free core — the run queue from Why Your Server Is Slow #1
  • Uninterruptible sleep (D): tasks asleep waiting, mostly for disk I/O to complete

The third item is the crux and the trap. Unlike other Unix systems, Linux counts tasks waiting on disk into load. So Linux load average isn’t “CPU load” — it’s closer to “demand waiting on CPU or disk.” CPUs can be idle while load soars because storage is jammed. Ordinary waits (network responses, locks, sleep) are S state and don’t count.

The yardstick — not absolute, but per core #

“Danger above 1.0” dates from single-core machines. Load counts demand, so it only means something against supply — the core count.

  • Load ≈ cores: demand roughly matches supply. Load 14 on a 16-core box is a healthy full house.
  • Load ≪ cores: headroom.
  • Load ≫ cores, sustained: tasks are queuing. Whether it’s CPU or disk, this number alone can’t say (we split them below).

Check cores with nproc. Inside containers, one more caution: load average is a host-wide value, blind to the container’s CPU limits — your neighbors’ load is mixed in.

The four classic divergences from CPU usage #

Load average and CPU utilization measure different things, so each mismatch has its own diagnosis.

UsageLoadTypical cause
High≈ coresNormal compute saturation; demand slightly over supply
LowHighDisk bottleneck — D-state tasks pushing load up; a frozen NFS server is the extreme case
High≫ coresCPU over-demand, including thread/worker counts far beyond cores
LowLow, yet slowWaiting that load can’t see (locks, network, upstream) — part 1’s territory

The second row is the Linux-specific trap. A server at “5% CPU, load 40” has a storage problem, not a CPU problem — and when an NFS server stops responding, every task touching that mount piles up in D state, producing the famous load-in-the-hundreds picture. Checking D state directly when load is high:

finding D-state tasks 
$ ps -eo state,pid,wchan:30,comm | awk '$1=="D"'
D  8123 rpc_wait_bit_killable  backup-agent
D  8124 rpc_wait_bit_killable  backup-agent

With wchan (what it sleeps waiting for) included, you narrow disk-vs-NFS in one shot.

1, 5, 15 minutes — the triple exists for trends #

The three values are exponential moving averages over roughly the last 1, 5, and 15 minutes. The comparison is the information, more than any single value.

  • 1min ≫ 15min (say 12, 4, 2): load is climbing right now. Look for what just started — a deploy, a batch job, a traffic surge.
  • 1min ≪ 15min (say 2, 6, 14): load is draining; you’re in the aftermath of something that just ended.
  • All three high and similar: a settled state — capacity or a bottleneck, not a spike.

For alerting, the 5-minute value resists momentary spikes well, and thresholds should be a multiple of core count (say, sustained 1.5× cores), not an absolute number — otherwise every instance-type change invalidates the alert.

The diagnostic order #

On a high-load alert:

  1. Normalize by cores — how many times nproc? And is the 1/5/15 pattern rising or settled?
  2. Compare with CPU usage — high usage means CPU demand; low usage points at D state.
  3. Count D state — ps with state and wchan; if it’s disk or NFS, continue with the iostat diagnosis.
  4. If it’s CPU, go to run queue diagnosis — vmstat’s r and per-process CPU ranking. The tool landscape is in RHEL Advanced #3.

Summary #

  • Linux load average is a moving average of running + runnable + disk-wait (D-state) task counts. It measures something different from CPU usage.
  • Read it against core count, not as an absolute. Load 14 on 16 cores is a full house, not an overload.
  • Low usage with high load points at D-state pileups (disk, and especially NFS); confirm with ps state and wchan.
  • The 1/5/15 triple is for trend: rising, draining, or settled — decide that first.
  • Set alert thresholds as multiples of core count; absolute thresholds die with the next instance resize.
X