Load average is a Unix and Linux metric that reports the average number of tasks that are running or waiting to run over the last 1, 5 and 15 minutes. Among server resources, it is one of the oldest and most quoted indicators of demand placed on a system, shown by commands such as uptime, top and w.
Load average is not a percentage and not the same as CPU utilization. It counts tasks, so its meaning depends on how many CPU cores the server has and on what the waiting tasks are waiting for.
How load average is calculated
The kernel calculates load average by sampling the number of active tasks about every five seconds and feeding that count into three exponentially damped moving averages. Recent samples weigh more than older ones, so the 1-minute value reacts quickly and the 15-minute value changes slowly.
On Linux, a task counts toward load when it is runnable, meaning it runs on a CPU or waits in the run queue, or when it is in uninterruptible sleep, shown as state D. Uninterruptible sleep usually means waiting for disk or network storage I/O. Most other Unix systems count only runnable tasks, so the same number can mean different things on different platforms.
| Task state | Symbol in ps | Counted in Linux load | Typical cause |
|---|---|---|---|
| Running or runnable | R | Yes | Using or waiting for a CPU |
| Uninterruptible sleep | D | Yes | Waiting for disk or NFS I/O |
| Interruptible sleep | S | No | Waiting for input, timers or network data |
| Stopped or zombie | T or Z | No | Suspended or finished, not yet reaped |
Interpreting the three values
Load average is interpreted relative to the number of CPU cores, including hardware threads reported by nproc. A load of 4.0 saturates a four-core server but leaves a 32-core server mostly idle.
| Load divided by cores | Meaning | Typical response |
|---|---|---|
| Below 0.7 | Spare capacity | No action needed |
| About 0.7 to 1.0 | Busy, little headroom | Watch trends and plan capacity |
| Above 1.0 | Tasks are queuing | Find out whether CPU or I/O is the cause |
| Far above 1.0 for long periods | Sustained overload | Reduce load, optimize or add resources |
These thresholds are rules of thumb, not limits. Some batch servers run comfortably above one task per core, while latency-sensitive services suffer earlier. The direction of the three values is equally useful: a 1-minute value well above the 15-minute value shows load rising, and the reverse shows it falling.
Load average compared with related metrics
Load average answers how much work is waiting, while neighboring metrics answer how busy or how constrained a specific resource is. Reading them together avoids false conclusions.
| Metric | What it measures | Unit | What it reveals |
|---|---|---|---|
| Load average | Runnable plus uninterruptible tasks | Number of tasks | Overall demand and queuing |
| CPU utilization | Share of time CPUs are busy | Percent | Whether CPUs are the bottleneck |
| I/O wait | Idle CPU time with pending I/O | Percent | Storage-related delays |
| Pressure stall information | Time tasks were stalled on CPU, memory or I/O | Percent of time | Which resource causes waiting |
| Swap activity | Pages moved to and from swap | Pages per second | Memory shortage |
A high load with low CPU utilization almost always points to tasks stuck in uninterruptible sleep, usually on slow storage or an unresponsive network file system. A high load with CPUs at 100 percent points to genuine CPU saturation.
Investigating high load
Investigating high load starts with separating CPU demand from I/O waiting. A short, repeatable sequence of checks usually locates the cause within minutes.
- Compare the load with the number of cores from nproc.
- Check CPU utilization and I/O wait with top, mpstat or vmstat.
- List tasks in state R or D with ps to see which processes are queuing.
- Check disk latency and queue depth with iostat for D-state tasks.
- Check memory and swap, since heavy swapping produces both I/O wait and load.
On modern kernels, pressure stall information in /proc/pressure gives a more direct answer by reporting the share of time tasks were delayed on CPU, memory or I/O. It complements load average rather than replacing it.
Common misconceptions about load average
- It is not CPU percentage: a load of 2.0 does not mean 200 percent CPU usage.
- It is not comparable across servers without dividing by core count.
- It is not an instant reading: even the 1-minute value lags sudden changes by many seconds.
- Linux load includes I/O waits, so storage problems raise it even when CPUs are idle.
- Containers usually see the host load, not the load of their own limited CPU share.
For alerting, sustained values matter more than brief spikes. Many teams alert on the 5-minute or 15-minute average per core and use the 1-minute value only to confirm that a problem is still active.
The simple explanation
Load average is like counting the people at a set of checkout counters, including those being served and those waiting in line. With four counters open, four people means everyone is served at once.
Eight people means four are waiting. The three numbers show the average crowd over one, five and fifteen minutes, so it is clear whether the line is growing or shrinking.
How it is used in practice
An administrator of an eight-core web server received an alert showing a load average of 24, 18 and 9. The rising pattern meant the problem had started within the last few minutes. However, top showed CPU utilization of only about 15 percent, so the CPUs were not the bottleneck.
Listing processes in state D revealed dozens of web workers waiting on an NFS mount that held uploaded images. The storage server behind the mount had become unresponsive after a network change. Once the network issue was fixed, the waiting tasks completed and the load dropped back below 4 within a few minutes. The team then added an alert on NFS latency so the root cause would be visible directly next time.