What Is Load Average and What Number Is Dangerous on a Server?

It's two in the morning, the site has slowed down, you log in via SSH and run uptime: load average: 14.62, 9.10, 4.33. The real question is whether 14 means disaster or means nothing. The short answer: it depends on the number of cores on that machine, and on whether that 14 comes from CPU or from disk.

The output of uptime gives three numbers: the average load over the past 1, 5, and 15 minutes. These numbers come from the Linux kernel and count the run queue; that is, processes that are either running on the CPU or waiting for their turn on the CPU, plus processes that are in state D (uninterruptible sleep) waiting for disk or network I/O. That last sentence is the whole story: load average is not just CPU.

Measure load average against the number of cores, not against a fixed number

The rule of thumb is this: divide the load by the number of logical cores. Below 0.7 per core means you're comfortable. Around 1 means full saturation but no queue. Above 1.5 per core means a queue has formed and users are waiting.

Get the number of cores with nproc or lscpu | grep '^CPU(s):'. On a four-core VPS, a load of 4 means maxed out; on a 32-core server, a load of 4 means idle. The load number alone means nothing.

One important point that many people miss: the trend. If the 1-minute load is higher than the 15-minute load, the problem is growing right now. If it's the opposite, you've passed a wave. That's why uptime gives three numbers and not one.

How to tell the difference between CPU load and I/O load

This is where most diagnoses go wrong. A load of 12 on a server whose CPU usage is 15 percent means the problem isn't CPU; it means disk.

Enter top and press 1 so each core is displayed separately, then look at the %wa (iowait) column. If this number stays above 20, the bottleneck is disk. With iostat -x 2 (from the sysstat package), look at the %util column; close to 100 means the disk is saturated.

iostat -x 2 5
# look at %util and await
# await above 50ms on an SSD means a serious problem

To see which process is stuck in state D, use ps:

ps -eo state,pid,comm | awk '$1=="D"'

If the output is full of mysqld or php-fpm, you most likely have a heavy query or a RAM shortage that has caused swapping. With vmstat 1, look at the si and so columns; any non-zero number there means the system is swapping, and this is the worst kind of load because it saturates the disk too.

Here's where people make a mistake: they solve high load by adding CPU. If the root cause is I/O, more cores only make the queue longer and the situation worse. The sign of this is: after upgrading the plan, the load is fine for two days and then returns to exactly the same number as before.

When load average is actually worrying

Look at three conditions together, not separately:

1. The 1-minute load is above 1.5 times the number of cores and is rising.
2. The site's response time (TTFB) has risen at the same time. High load without user slowdown usually means a batch job is running and there's no problem.
3. The 15-minute load has also stayed high. A short spike during the nightly backup is normal.

If all three hold, it's a real problem. If only the first holds, you're probably reacting to an insignificant number.

A common trap in WordPress: wp-cron.php that runs on every user visit. When traffic rises, dozens of simultaneous instances of it run and drive the load up. The solution is to disable the internal cron and replace it with a real system cron; the details are in WordPress wp-cron; why it doesn't run and how to replace it with a real cron. If you're on shared hosting and don't have access to system cron, Linux hosting with full access makes this possible.

Tools that are actually useful

htop for a quick look, atop for retrospective analysis (because it keeps a history of load and disk), and sar -q for seeing the load trend over the past 24 hours. If you've just set up the server and want to establish a baseline, enable sar from day one; later, without historical data, you won't be able to say whether a load of 8 is normal for this server or not.

For a quick check from the outside, ServerNet's free tools provide a speed test and server response check. If you're seeing an HTTP error and don't know where it's coming from, HTTP status codes: a practical guide to common errors is a good starting point.

And if the problem is a WordPress plugin that reads the entire database every time, before doing anything else, perform a WordPress plugin audit. In my experience, more than half of loads above 10 on WordPress servers come from two or three badly written plugins, not from a lack of resources.

Frequently asked questions

What load average is good?

There is no absolute number. Divide the load by the number of cores; below 0.7 per core is good, and above 1.5 per core means queueing and latency. On an 8-core server, a load of 5 isn't worrying, but a load of 14 is.

Why is load average high but CPU usage low?

Because processes are in uninterruptible sleep (D) waiting for disk or network I/O, and Linux counts them in the load too. Look at the %wa column in top and %util in iostat -x; if they're high, the bottleneck is disk, not the processor.

Does adding CPU bring the load down?

Only if the bottleneck is truly CPU. If the root cause is I/O, a RAM shortage, or swap, more cores hide the problem and after a short while the load returns to the same number. First find the root cause with vmstat and iostat.

What's the difference between load average and CPU usage?

CPU usage tells you what percentage of its time the processor is working; load tells you how many tasks are in the queue. A CPU can be 100 percent busy with a load of 1, or 10 percent busy with a load of 20 because the rest are waiting on disk.

Next step: right now, put nproc and uptime side by side and calculate the ratio. If it's above 1.5, before doing anything else, open top and press 1 to see whether that load comes from CPU or from %wa. That one look finishes half the diagnosis.