Linux load average: runnable work, blocked tasks and CPU pressure
Interpret Linux load average alongside runnable tasks, CPU utilization and pressure signals. Diagnose high load without assuming the machine needs more CPU.
TL;DR: Linux load average includes runnable tasks and tasks in uninterruptible sleep. Identify which group is growing, then compare CPU availability, pressure and application latency before choosing a remedy.
What the number counts
A runnable thread is executing or waiting for CPU time. A task in uninterruptible sleep, commonly shown as D, is waiting inside the kernel; storage waits are a frequent cause. An ordinary sleeping task waiting for a timer or network response does not automatically count toward load. The Linux load-average interface exposes the familiar one-, five- and fifteen-minute figures plus the current runnable and total task counts.
Those averages have memory. They do not instantly return to normal when a short burst ends. A load of 16 also has no percentage sign: it describes demand and blocked work, while CPU utilization describes time spent executing. Dividing load by a machine's CPU count is useful only after checking why those tasks are counted and which CPUs the workload can actually use.
Two hosts with the same load
Consider two hypothetical eight-vCPU servers, both showing a one-minute load near 16. On host A, CPU execution is near its available capacity, sampled runnable queues remain long, and requests wait before doing useful work. On host B, CPUs spend much of their time idle while many worker threads sit in D and storage completion latency rises. More CPU is a plausible experiment for A if the work parallelizes. It does little for B's blocked storage path.
The comparison needs synchronized observations. A load average from the previous minute and a CPU sample from an idle second can create a false contradiction. Capture a short time series during the symptom, including request rate, rather than collecting one screenshot after recovery.
| Observation | Working explanation | Evidence to collect next |
|---|---|---|
| Runnable threads rise with busy CPUs | Execution demand exceeds effective CPU supply | Per-thread CPU and available CPU set |
Many D tasks with low CPU execution | Threads wait inside the kernel | Wait sites, storage latency and pressure |
| One container stalls on a quiet host | Local limit or placement constraint | Its quota, CPU set and throttling counters |
| Load remains high after recovery | Averaging retains earlier demand | Current queue and latency trend |
On a Linux host with procps utilities, these read-only commands provide a starting point:
cat /proc/loadavg
ps -eLo pid,tid,stat,pcpu,wchan:24,comm
vmstat 1 5
cat /proc/pressure/cpu
cat /proc/pressure/io
ps is a snapshot, and its CPU percentage is not necessarily the same interval as vmstat. Ignore vmstat's first report when comparing the following interval samples: it summarizes time since boot. A wait-channel name can narrow a hypothesis but cannot establish the full dependency chain. Permissions and kernel configuration can also hide that name.
Locate the capacity boundary
An eight-vCPU host can contain a workload restricted to two CPUs or to a smaller CPU-time quota. Host-level idle time therefore cannot disprove container throttling. Read the workload's effective CPU set and its own CPU accounting. The cgroup v2 CPU interface documents quota and throttling counters; CPU quotas explains how a service can exhaust its allowance before the period ends.
Pressure Stall Information helps distinguish demand from lost progress. Its some measurement tracks time when at least one task is stalled on the resource; full has a different meaning and system-level CPU full is undefined. Use the kernel PSI documentation to interpret those fields, and prefer the affected cgroup's pressure where available. Pressure is evidence of contention, not an automatic instruction to resize.
An interview follow-up often changes just one constraint: the service has a single busy worker. Adding replicas may distribute independent requests, while adding CPUs to the same process may leave its serial bottleneck untouched. Explain the execution model before prescribing capacity. For a blocked host, reduce the offending concurrency or restore the dependency when evidence supports it, then check useful throughput as well as latency.
Check your reasoning
A four-vCPU container host reports load 12 and moderate CPU utilization. One batch job has many D threads; API latency increases at the same time. Does load divided by four prove 300% CPU demand?
No. The quotient mixes runnable work with blocked tasks. Inspect the batch job's waits and shared storage or memory pressure, then compare the API's own CPU allocation and throttling. Pausing a restartable batch task is a bounded experiment if it reduces shared contention. A falling load average alone is insufficient evidence of recovery; request latency and successful work must recover too.