Load average is one of the most misread metrics on Linux. This page explains what 1/5/15 means, the per-core formula, and the exact steps to separate CPU load from I/O wait.
What is Load Average on Linux?
Linux load average is a running exponential average of the number of processes in the run queue (state R) plus processes waiting for uninterruptible I/O (state D), sampled over the last 1, 5, and 15 minutes. The critical distinction: a process blocked on disk I/O counts the same as a process actively using CPU. This is why a server can show load average 12.5 while top reports only 15% CPU — the remaining load is 85% iowait from a backup job hammering the disk. The threshold that matters is load per core. On a 4-core server, load average 4.0 means the system is fully loaded. Load average 2.0 means 50% utilisation. Load average 8.0 means processes are queuing and waiting for CPU or I/O access. The 1/5/15 triplet tells you the trend: if 1-minute is much higher than 15-minute, load is spiking right now. If 15-minute is higher than 1-minute, load is coming down from a recent peak. A sustained 5-minute average above your core count is the threshold to investigate.
Tools and Commands
# Quick load average check
uptime
# Show load, logged-in users, and per-user activity
w
# CPU breakdown including iowait (run every 1 second, 5 times)
iostat -c 1 5
# Full CPU and disk I/O breakdown together
iostat -x 1 5
# Top with per-core view (press '1' inside top)
top -d 1
# vmstat run queue and blocked processes
vmstat 1 5The key diagnostic step is running iostat -c 1 5 alongside top simultaneously. iostat shows the %iowait column which directly tells you how much of the load is disk-driven. If %iowait is above 20% and CPU user+system is below 30%, the load is I/O-driven and the fix is at the disk or database layer. vmstat adds the r (runnable) and b (blocked on I/O) columns — a high b count confirms I/O wait as the cause.
Key Parameters
| Flag / Parameter | Description | Security Note |
|---|---|---|
uptime (1/5/15 values) | Three load average figures: last 1 minute, 5 minutes, 15 minutes. Divide by core count for utilisation percentage. | Rule of thumb: if any figure exceeds core count, the system is over-loaded. Investigate if 5-minute average stays above core count for more than 2-3 minutes. |
iostat -c | Report CPU statistics only (no disk output). Shows %user, %system, %iowait, %steal, %idle. | Run with interval 1 and count 5-10. A single sample from iostat includes time since boot — repeated samples show the real current state. |
iostat -x | Extended disk statistics: %util, await, svctm per device. Use to confirm which device is causing iowait. | Focus on %util and await. A device at 100% util with await above 20ms is saturated and is causing the iowait load. |
vmstat r column | Number of processes in the runnable queue (waiting for CPU). Excludes I/O blocked processes. | If r is consistently above core count, the load is CPU-bound. If r is low but b (blocked) is high, the load is I/O-bound. |
vmstat b column | Number of processes blocked on uninterruptible I/O. High b directly explains high load average without high CPU. | b above 3-5 sustained means disk I/O is a bottleneck. Run iotop -o to find which processes are generating the I/O. |
Diagnosis and Fix Workflows
4-core server with load 12.5 — separating iowait from CPU load
Load average 12.5 on a 4-core server (3x the core count) looks alarming. But before taking any action, run iostat -c 1 5 and top simultaneously. If top shows CPU at 18% user + 7% system = 25% total CPU, and iostat shows %iowait at 78%, then 78% of all CPU time is spent waiting for disk. The actual CPU load contributing to load average from computing processes is low — the high load average is driven almost entirely by processes blocked on I/O.
# Run both simultaneously to see CPU vs iowait
iostat -c 1 5 &
top -d 1
# Or use vmstat to see r vs b split:
vmstat 1 10Trending load average — is the problem getting worse?
The three numbers in uptime output give you trend information without any additional tools. If the sequence is 8.2, 5.1, 3.4 (1min higher than 5min higher than 15min), load is currently spiking. If it reads 2.1, 4.8, 7.2 (15min highest), the system was under heavy load recently and is now recovering. This helps prioritise urgency: a rising trend needs immediate investigation, a falling trend can wait for the cause to be identified from logs.
# Display load with timestamp
uptime
# Monitor every 10 seconds
watch -n 10 uptimeIdentify the iowait-generating process after confirming I/O load
Once iostat -c confirms high iowait is the cause of load, identify which process is generating the disk I/O with iotop. The -o flag shows only processes actively performing I/O. If it is a backup job running rsync or tar, consider scheduling it outside peak hours or using ionice -c 3 to run it at idle I/O priority.
# Show only processes doing I/O right now
iotop -o -n 5
# Run backup at idle I/O priority
ionice -c 3 rsync -av /data/ /backup/Performance Impact: Misreading Load Average Leads to Wrong Fixes
The most common mistake when seeing high load average is immediately looking for CPU-hungry processes to kill. On a server where iowait is 70% of load, killing processes has no effect — the load is driven by blocked I/O, not CPU competition. Conversely, adding more RAM or upgrading disk does nothing for a server where the load is 100% CPU-bound from a runaway process. Getting this diagnosis wrong wastes time and may cause unnecessary downtime from restarting services that are not the cause. Sustained high load average above 2x core count causes measurable user impact: request queuing at the web server layer leads to timeout errors for users waiting for workers to become available. PHP-FPM and Apache prefork have fixed worker pools — when workers are all blocked waiting for slow I/O (slow MySQL queries writing to a loaded disk), new HTTP requests queue and eventually hit the connection accept backlog limit, triggering 502 or 503 errors. Identifying whether load is CPU or I/O bound is the first step that must be correct before any other action.
- Load average above 2x core count sustained for 2+ minutes causes web server worker pool exhaustion and 502/503 errors for users.
- Killing processes to reduce load will not help if the load is driven by iowait — the blocked I/O processes will be replaced by new ones.
- A single backup job using rsync or mysqldump without ionice can drive iowait above 80% and effectively halve the server's request handling capacity.
- Do not read load average without dividing by core count — a load of 4.0 is critical on a 2-core VPS and completely normal on a 16-core server.
Practical Examples
Diagnose a 4-core server with load 12.5 using iostat and top simultaneously
# Terminal 1: CPU breakdown including iowait
iostat -c 1 10
# Terminal 2: per-core view and top processes
top -d 1 # press '1' for per-core
# Quick combined check with vmstat:
vmstat 1 10If %iowait in iostat is above 50% while CPU user+system is below 30%, the load is I/O-driven. If vmstat shows b (blocked) is high and r (runnable) is low, confirm with iotop -o to find the I/O-generating process.
Calculate safe load average threshold for your server
# Get core count
nproc
# Or:
grep -c ^processor /proc/cpuinfo
# Safe thresholds:
# Warning: load > nproc * 0.7
# Critical: load > nproc * 1.0
# Emergency: load > nproc * 2.0On a 4-core server, warning threshold is 2.8, critical is 4.0. These are rules of thumb — the actual acceptable load depends on whether the load is CPU or I/O bound and how latency-sensitive the workload is.
Run a backup at idle I/O priority to prevent load spikes
# Run rsync at idle I/O priority (class 3 = idle)
ionice -c 3 rsync -av --progress /var/www/ /backup/www/
# Or set ionice for an already-running PID
ionice -c 3 -p $(pgrep rsync)ionice class 3 (idle) means the process only gets disk access when no other process needs it. This prevents backup jobs from generating iowait that impacts web server response times during business hours.
Troubleshooting Common Issues
Problem: Load average is high but both CPU and iowait are low
Solution: Check for processes in D state (uninterruptible sleep on something other than disk). This can include NFS mounts that have become unresponsive, or kernel lock contention. Run ps aux | awk '$8 == "D"' to list D-state processes and identify what they are waiting on.
Problem: Load average spikes every hour or day at a predictable time
Solution: Check cron jobs: grep -r '' /etc/cron.* /var/spool/cron/crontabs/ 2>/dev/null. Also check systemd timers: systemctl list-timers. Correlate the spike time with cron timing to identify the job. Run the job with nice -n 15 and ionice -c 2 -n 7 to reduce its CPU and I/O priority.
Problem: Load average does not decrease after fixing the suspected cause
Solution: The 1-minute average takes roughly 5 minutes to fully reflect a change. The 5-minute average takes 10-15 minutes. If 15 minutes after fixing the cause the 5-minute average is still high, there is a second source of load. Use vmstat 1 30 to get 30 seconds of data and look for sustained r or b columns.
Summary
Load average divided by core count gives you utilisation percentage. Always check iostat -c 1 5 and vmstat before acting — %iowait distinguishes I/O-bound from CPU-bound load, and the r/b columns confirm which type of blocking is driving the number. The 1/5/15 trend tells you whether load is rising or falling. Act on the 5-minute average, not the 1-minute spike.
- Divide load average by
nprocfor the real utilisation figure — a load of 8.0 on a 16-core server is 50% utilisation, not an emergency. - Run
iostat -c 1 5immediately when load is high — if%iowaitis above 30%, the cause is disk I/O, not CPU, and process-level tools are the wrong fix. - Use
vmstat 1 5and compare ther(runnable) andb(blocked) columns to confirm whether load is CPU-bound or I/O-bound before taking any action.
Related Commands
iostat to separate I/O wait from CPU load • vmstat for blocked processes and swap pressure • diagnosing high CPU with pidstat and strace • MySQL InnoDB buffer pool to reduce I/O load
Is Your Server Running at Full Performance?
INTRAM manages Linux servers with performance tuning built in from day one — correct MySQL configuration, PHP stack selection, nginx or Apache optimisation, and continuous monitoring so slowdowns are caught before users notice.
Explore Managed Hosting