Load average is printed by uptime, top, htop, and /proc/loadavg, and it’s one of the most frequently misread numbers in Linux administration. Many people assume it’s a CPU percentage. It isn’t, and understanding what it actually counts changes how you should react to it.

Where to See It

uptime

14:32:07 up 23 days, 4:12, 3 users, load average: 0.42, 0.58, 0.61

Or read it directly:

cat /proc/loadavg

0.42 0.58 0.61 2/487 18234

The first three numbers are the load averages. The fourth field (2/487) shows currently runnable processes over total processes, and the last number is the most recently created process ID.

What Load Average Actually Counts

Load average is the average number of processes that are:

1. Actively running on a CPU right now, or
2. Waiting for a turn on a CPU (runnable but not currently scheduled), or
3. Waiting on uninterruptible I/O, most commonly a process blocked on disk access

That third category is a Linux-specific choice (some other Unix variants only count the first two). It means load average is not a CPU-only metric. A system can show high load average while the CPU itself sits mostly idle, because processes are queued up waiting on slow disk I/O rather than competing for CPU cycles.

Why Three Numbers

The three values represent averages over the last 1, 5, and 15 minutes. Reading them together tells you the direction of change:

• 1-min > 5-min > 15-min: load is climbing, possibly still rising
• 1-min < 5-min < 15-min: load spiked earlier and is now settling down
• All three roughly equal: load has been steady

A single load number tells you almost nothing about trend. Three numbers side by side tell you whether you’re looking at the start, middle, or tail end of a load event.

The Number That Actually Matters: Core Count

A load average of 6 means something completely different on different hardware:

nproc

• On a 4-core machine, a load average of 6 means the CPU has more demand than it can serve; processes are queuing.
• On a 32-core machine, a load average of 6 is trivial, well under half of available capacity.

There is no meaningful “good” or “bad” load average without knowing the core count. The commonly cited rule of thumb, sustained load at or below core count, is a reasonable starting point for latency-sensitive services, but batch-processing systems designed to keep every core busy can run comfortably at or above that line.

Load Average vs. CPU Usage: A Common Mismatch

It’s entirely possible to see high load average alongside low CPU usage in top. This happens when many processes are stuck in uninterruptible I/O wait rather than competing for CPU. The giveaway combination:

• uptime or top shows elevated load average
• top’s CPU summary shows low us/sy (user/system time) but a high wa (I/O wait)
• vmstat 1 shows a nonzero, sometimes large, b column (processes blocked on I/O)

This pattern points to a storage bottleneck, not a CPU bottleneck. Chasing CPU optimizations in this scenario won’t help; the fix lives in the storage layer (checking iostat for a saturated disk, a runaway I/O-heavy process via iotop, or misbehaving network storage).

A Practical Triage Sequence

1. uptime, get the three load numbers and eyeball the trend
2. nproc, know your core count for context
3. top or htop, check whether us/sy (CPU-bound) or wa (I/O-bound) dominates
4. If CPU-bound: identify the process, consider nice/renice, or scale
5. If I/O-bound: run iostat -xz 1 to find the saturated device, iotop to find the responsible process

Frequently Asked Questions

What does load average actually measure?

Load average is the average number of processes that are either actively running on a CPU, waiting for a turn on a CPU, or on Linux specifically, waiting on uninterruptible I/O such as disk access. It is not a CPU usage percentage. A load average of 4 does not mean 4 percent or 400 percent of anything by itself; it means, on average, 4 processes wanted CPU time or were stuck on I/O during that window.

How do I know if a load average number is high or low?

Compare it against the number of CPU cores available, found with nproc. A load average roughly equal to or below the core count generally means the CPU is keeping up with demand. A load average significantly higher than the core count means more processes want to run than there are cores to run them on, and they are queuing. A load average of 8 on a 4-core machine indicates real contention; the same number on a 32-core machine is barely a blip.

Why does Linux load average include processes waiting on disk I/O?

This is a deliberate design decision inherited from early Unix and kept in Linux: processes in uninterruptible sleep, most commonly waiting on disk I/O, are counted toward load because they represent work the system is not able to make progress on, which is meaningfully similar to being blocked waiting for CPU. This means a load average spike can indicate an I/O bottleneck rather than a CPU bottleneck, which is a common source of confusion when troubleshooting.

Why are there three load average numbers instead of one?

The three numbers, typically shown as 1-minute, 5-minute, and 15-minute averages, let you see the trend rather than a single noisy snapshot. If the 1-minute number is much higher than the 15-minute number, load has spiked recently and may still be climbing. If the 1-minute number is lower than the 15-minute number, whatever caused elevated load has already started easing off.

Can load average be high while CPU usage looks low in tools like top?

Yes, and this is one of the most common points of confusion. If many processes are stuck waiting on disk I/O rather than using the CPU, load average rises because those processes are counted, but top will show low CPU utilization because the CPU itself is idle waiting for I/O to complete. This combination (high load, low CPU usage, high wa in vmstat or top) is a strong signal of an I/O bottleneck, not a CPU bottleneck.

What is a normal load average for a typical Linux server?

There is no universal number, since the right target depends entirely on core count and workload type. A commonly used rule of thumb is keeping sustained load average at or below the number of CPU cores for latency-sensitive workloads, allowing brief spikes above that during traffic bursts. Batch-processing systems that are expected to be fully utilized can run with load average intentionally at or slightly above core count without it indicating a problem.