Start with a simple mental model

Imagine a small workshop with 4 workers. Jobs arrive continuously. A worker can handle one job at a time.

Workers available: 4
Jobs needing attention: 2

Two workers can handle those jobs immediately. There is spare capacity.

Workers available: 4
Jobs needing attention: 4

All workers are occupied. The workshop is busy, but jobs do not necessarily have to wait.

Workers available: 4
Jobs needing attention: 8

Now there is more work than the workers can handle at once. Some jobs must wait.

This is a useful first picture for load average. On a Linux system, however, the “jobs needing attention” are not limited to processes actively using CPU. We will refine that model shortly.

What do the three load numbers mean?

Run:

uptime

19:42:16 up 11 days,  6:27,  2 users,  load average: 1.20, 2.80, 5.60

The three values are approximately:

What to check: compare the recent number with the longer windows. Here 1.20 < 2.80 < 5.60, so the system was under more pressure earlier and is recovering.

If you instead saw 5.60, 2.80, 1.20, recent pressure would be increasing.

Now the technical truth

The worker analogy is useful, but Linux load average is broader than “how many processes are using the CPU.” Linux counts tasks that are runnable and tasks in uninterruptible sleep—commonly tasks waiting for I/O.

That is why this statement is wrong:

Load average 8.0 = CPU is 800%

A high load can come from CPU demand, blocked I/O, or a mixture of both. Load tells you pressure exists; other evidence tells you what kind of pressure.

Compare load with available CPU capacity

First find how many processing units Linux makes available to the workload:

nproc

4

On this system, a sustained load around 4 means roughly four tasks are continuously demanding attention. A sustained load much above 4 means work is queueing somewhere—but you still need to determine whether it is CPU or blocked I/O.

Three examples on a 4-CPU system

Example 1 — Plenty of capacity

load average: 0.85, 0.72, 0.68

The system has four CPUs and less than one task on average demanding attention. Load itself does not suggest pressure.

Example 2 — Busy but not automatically unhealthy

load average: 3.90, 3.75, 3.62

This is close to the available CPU count. If the workload is expected and latency is healthy, there may be nothing to fix. Check CPU states and application symptoms before calling it a problem.

Example 3 — Work is building up

load average: 9.40, 7.20, 4.10

The 1-minute value is well above both CPU count and the longer windows. Pressure is increasing. Your next question is not “how do I reduce load?” It is “what is making tasks wait?”

High load does not always mean high CPU

Use top to see whether CPUs are actually busy:

top

top - 19:49:10 up 11 days,  load average: 9.84, 7.15, 4.52
%Cpu(s):  8.7 us,  2.4 sy,  0.0 ni, 54.5 id, 34.1 wa,  0.0 hi,  0.3 si,  0.0 st

What to check: the CPUs are more than half idle (54.5 id) while I/O wait (34.1 wa) is high.

What it means: blaming CPU saturation would be a poor conclusion. The load may be coming from tasks blocked on I/O.

Next: move into storage/I/O evidence using the Disk I/O Troubleshooting runbook.

For every field in this screen, use Understanding the Linux top Command.

A quick second opinion with vmstat

vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 824312  69124 982144    0    0     3    18  310  520 21  5 73  1  0
 8  5      0 801420  69124 991228    0    0 16384 12800 1300 2210 12  4 42 42  0

What to check: r is runnable work, b is tasks blocked in uninterruptible sleep, and wa is CPU time waiting for I/O.

Interpretation: the second sample shows both a larger runnable queue and several blocked tasks while wa rises to 42%. That supports an I/O-pressure hypothesis much more strongly than load average alone.

Find tasks stuck in uninterruptible sleep

ps -eo state,pid,comm,wchan:32 | awk '$1 ~ /^D/'

D 18422 python3          io_schedule
D 18491 postgres         wait_on_page_bit_common

What to check: processes in state D. A few transient D-state tasks are normal. Many tasks remaining there while load is high can explain why load rises even when CPU utilization is modest.

Next: investigate the resource those tasks are waiting on rather than killing processes blindly.

How to read the trend

Load average vs CPU utilization

These answer different questions:

That difference is one of the most important Linux performance concepts to understand.

Interview questions worth knowing

A 4-core server has load average 8. Is CPU usage 100%?

No. It tells you demand is high relative to four available CPUs, but Linux load can also include tasks in uninterruptible wait. Check CPU states, runnable/blocked tasks and I/O evidence.

What are the three numbers?

Approximately the 1, 5 and 15 minute load averages, with the kernel using exponentially damped historical values rather than simple bucket averages.

Can load be high while CPU is mostly idle?

Yes. Tasks blocked in uninterruptible sleep can contribute to load. Storage or other I/O problems are a common reason.

Is load 4 bad on a 4-CPU server?

Not automatically. It means the system is around that level of demand. Whether it is unhealthy depends on latency, workload expectations, sustained trends and where time is being spent.

Which number matters most?

None in isolation. The 1-minute value helps detect recent changes, while 5- and 15-minute values show whether pressure is sustained or recovering.

A practical troubleshooting sequence

1. Check uptime/load trend
2. Check available CPUs with nproc
3. Inspect CPU states and processes with top
4. Use vmstat to separate runnable work from blocked/I/O pressure
5. Follow the evidence into CPU, disk I/O, memory or another subsystem

If the symptom is a generally slow host, start with Linux Server Running Slow. If CPU is clearly saturated, continue with High CPU Usage.