Understanding Linux Load Average: Meaning, Measurement, and Real‑World Cases

What Is Average Load

Average load is often confused with CPU usage, but it actually represents the average number of processes in runnable or uninterruptible states over a period of time – essentially the average number of active processes.

Runnable State

Processes that are using the CPU or waiting to be scheduled (shown as R in ps).

Uninterruptible State

Processes in kernel mode that cannot be interrupted, such as those waiting for I/O (shown as D in ps).

When a process performs disk I/O, it stays in this state until the operation completes, protecting data consistency.

Thus, average load can be seen as the average number of active processes. An ideal load equals the number of CPUs, meaning each CPU runs exactly one process. For example, a load of 2 on a 2‑CPU system means full utilization, while on a 4‑CPU system it indicates 50 % idle.

Average Load vs. CPU Utilization

Average load includes both CPU‑bound and I/O‑bound processes, whereas CPU utilization only measures how busy the CPU is. Consequently, high load does not always mean high CPU usage:

CPU‑intensive processes raise both load and utilization.

I/O‑intensive processes raise load but may keep CPU utilization low.

Many processes waiting for CPU raise both load and utilization.

Practical Load‑Average Cases

Scenario 1 – CPU‑Intensive Workload

1. Run a stress command to consume 100 % CPU: $ stress --cpu 1 --timeout 600 2. In another terminal, monitor load with uptime: $ watch -d uptime 3. In a third terminal, check CPU usage with mpstat: $ mpstat -P ALL 5 20 The load rises to about 1.62 while one CPU shows 100 % usage and no I/O wait, confirming the load increase is caused by CPU load.

Identify the offending process with pidstat: $ pidstat -u 5 1 The stress process is responsible.

Scenario 2 – I/O‑Intensive Workload

1. Generate I/O pressure with stress‑ng:

# --hdd creates temporary files
# -i spawns workers that repeatedly call sync()
$ stress-ng -i 4 --hdd 1 --timeout 600

2. Monitor load with uptime in a second terminal.

3. Observe CPU statistics with mpstat: $ mpstat -P ALL 5 20 Load climbs to about 1.71 while CPU idle drops and I/O wait rises, indicating the load increase is driven by I/O wait.

Use pidstat to find the culprit: $ pidstat -u 5 1 The stress‑ng process is responsible.

Scenario 3 – Over‑Subscribed Processes

Run eight CPU‑bound processes on a four‑CPU system: $ stress -c 8 --timeout 600 The system reports a load average above 4, showing severe overload. pidstat reveals each process spends a large portion of time waiting for CPU (%wait up to 50 %).

These examples demonstrate how to interpret load average, differentiate it from CPU utilization, and use common Linux tools to diagnose performance issues.