Understanding Linux Load Average: Meaning, Measurement, and Real‑World Cases
This article explains what Linux load average actually measures, distinguishes it from CPU utilization, and demonstrates how to interpret and monitor load with practical stress‑test scenarios using tools like uptime, mpstat, and pidstat.
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
Rin
ps).
Uninterruptible State
Processes in kernel mode that cannot be interrupted, such as those waiting for I/O (shown as
Din
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:
<code>$ stress --cpu 1 --timeout 600</code>2. In another terminal, monitor load with
uptime:
<code>$ watch -d uptime</code>3. In a third terminal, check CPU usage with
mpstat:
<code>$ mpstat -P ALL 5 20</code>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:
<code>$ pidstat -u 5 1</code>The
stressprocess is responsible.
Scenario 2 – I/O‑Intensive Workload
1. Generate I/O pressure with
stress‑ng:
<code># --hdd creates temporary files
# -i spawns workers that repeatedly call sync()
$ stress-ng -i 4 --hdd 1 --timeout 600</code>2. Monitor load with
uptimein a second terminal.
3. Observe CPU statistics with
mpstat:
<code>$ mpstat -P ALL 5 20</code>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
pidstatto find the culprit:
<code>$ pidstat -u 5 1</code>The
stress‑ngprocess is responsible.
Scenario 3 – Over‑Subscribed Processes
Run eight CPU‑bound processes on a four‑CPU system:
<code>$ stress -c 8 --timeout 600</code>The system reports a load average above 4, showing severe overload.
pidstatreveals 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.
Efficient Ops
This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.