A high Linux load average does not necessarily mean the processors are busy. The common claim that “load average measures CPU usage” confuses two related but distinct signals.
Linux calculates load average from the number of tasks that are runnable and the number stuck in uninterruptible sleep. Runnable tasks are executing on a CPU or waiting for one. Tasks in uninterruptible sleep, usually shown as state D by tools such as ps, are waiting for a kernel operation to finish and cannot currently handle ordinary signals.
Storage I/O is a frequent cause of uninterruptible sleep. Suppose many processes read from a slow or unavailable disk. Those processes may spend most of their time waiting rather than executing instructions. CPU utilization can remain low, yet the load average rises because Linux still includes those waiting tasks in its load calculation.
This distinction explains why load average and CPU utilization must be read separately. CPU utilization reports how much processor time is being consumed. Load average reflects sustained demand from runnable tasks plus certain blocked tasks. It is therefore possible to observe a load average of 20 alongside mostly idle CPUs when many processes are waiting in D state.
The three familiar values in /proc/loadavg and commands such as uptime are exponentially weighted averages over approximately one, five, and fifteen minutes. They are not instantaneous counts. A short disturbance can keep the one-minute value elevated after the underlying problem has disappeared, while the longer values reveal whether the pressure is persistent.
CPU count still matters when runnable work is responsible for the load. A load near eight may indicate saturation on an eight-CPU system because roughly eight tasks can run simultaneously. But that interpretation fails if much of the count comes from uninterruptible sleepers. Dividing load average by CPU count does not transform it into a reliable utilization percentage.
When load is high but CPU usage is low, inspect task states before adding processor capacity. Commands such as ps can reveal D-state processes, while storage latency, network-backed filesystems, device failures, and kernel waits may identify the resource actually causing the queue.
Load average is best treated as a pressure clue. It says that tasks are accumulating, but CPU metrics and process states are needed to determine why.
Top comments (0)