Linux Load Average Explained: What the 3 VPS Numbers Mean

You SSH into your VPS to check on something unrelated, run uptime out of habit, and see load average: 4.32, 3.98, 3.15. Is that bad? Is your server about to fall over? If you've never had someone explain what those three numbers actually track, they look alarming no matter what they say — and most guides just tell you "keep it under your core count" without explaining why, which doesn't help when the number is sitting right on the line.

What Load Average Actually Measures

Load average is not CPU usage as a percentage. It's a count of processes that are either running on a CPU or waiting in line for one (technically, waiting in the "run queue" or in uninterruptible sleep, usually for disk I/O). A load of 1.0 on a single-core system means, on average, exactly one process was using or waiting for the CPU — the system was fully busy but nothing was queued up behind it.

The three numbers are exponentially-weighted moving averages over the last 1, 5, and 15 minutes. Reading them together tells you a trend, not just a snapshot:

• 1-minute number lower than the 5 and 15-minute numbers — load is easing off. Whatever spiked things is settling down.
• 1-minute number higher than the 5 and 15-minute numbers — load is climbing right now. Worth watching.
• All three close together and high — sustained load, not a blip. This is the pattern that usually needs action.

The Number Means Nothing Without Your Core Count

This is the part most people skip. A load average of 4.0 is a non-event on an 8-core VPS and a five-alarm fire on a 1-core one. Check your core count first:

nproc
# or
cat /proc/cpuinfo | grep -c processor

Then divide load average by core count to get a rough utilization ratio:

A 4-core VPS sitting at a load average of 3.2 is around 0.8 per core — busy, but not in trouble. The same 3.2 on a single-core box means over three tasks are queued for every one that's running, and every request is waiting its turn.

Symptom: Site Feels Slow but CPU Graphs Look Fine

This is the scenario that trips people up most. You check a CPU usage percentage graph in your control panel and it says 40%, but the site is crawling. Load average often explains this gap, because it counts processes waiting on disk I/O too, not just CPU-bound work. A load average that's high while CPU usage looks moderate is a strong hint the bottleneck is disk, not processor — a slow disk, a saturated database, or too many processes waiting on the same lock.

Confirm it with:

top
# press 1 to see per-core usage, watch the %wa (iowait) column

vmstat 2 5
# the 'b' column shows processes blocked waiting on I/O

If %wa is consistently above 5-10%, your CPUs are sitting idle waiting for disk reads or writes to finish, which is exactly the kind of thing raw CPU-percentage graphs undersell.

Cause: What's Actually Driving the Number Up

Once you know the load is real and sustained, find out what's queuing. Start broad, then narrow:

# which processes are eating CPU right now
ps aux --sort=-%cpu | head -10

# which are eating memory (can cause swapping, which drives load up too)
ps aux --sort=-%mem | head -10

# live view, sorted by CPU
top -o %CPU

On a shared WordPress box, the usual suspects are:

• MySQL/MariaDB running unindexed queries — check with the slow query log
• PHP-FPM workers piling up because a plugin or theme function is slow, and requests are queuing behind each other
• A cron job or backup script running at the same time as normal traffic, competing for the same disk
• A bot or scraper hammering a search or filter page that triggers a heavy, uncached database query on every hit
• Swapping — if RAM is full and the kernel starts swapping to disk, load average climbs because everything backs up waiting on that much slower disk I/O

If free -h shows swap usage climbing alongside load average, treat it as a memory problem first — fixing the swap will usually bring load down on its own.

Fix: Bringing It Back Down

The fix depends on what you found above, but the common ones:

1. Slow queries — add the missing index, or cache the query result at the application layer so it isn't re-run on every page load.
2. Too many PHP-FPM children queuing — check pm.max_children in your PHP-FPM pool config isn't set so low that requests stack up; but also check it isn't set so high that you're oversubscribing RAM and triggering swap.
3. A single runaway process — identify it with ps aux --sort=-%cpu and either kill it, rate-limit it, or move it to a less busy time via cron.
4. Bot traffic — add rate limiting at the web server or firewall level (fail2ban, ModSecurity, or Cloudflare rules) rather than trying to out-scale it with more resources.
5. Genuinely outgrown the plan — if load is consistently near or above your core count during normal traffic, not just during spikes, that's a sign to upgrade cores rather than keep chasing individual queries.

Prevention: Watch the Trend, Not Just the Snapshot

A single high reading from uptime tells you almost nothing on its own — you need a baseline. Note what your load average normally looks like during quiet hours and during your typical traffic peak, so you can tell "this is Tuesday's normal peak" from "this is new and getting worse."

A few habits that catch problems before they become outages:

• Set up an alert (via a monitoring agent or a simple cron + email script) if load average per core stays above 1.5 for more than a few minutes
• Review the slow query log weekly on any site with real traffic, not just when things feel slow
• Stagger cron jobs and backups so they don't all fire in the same window as your traffic peak
• Recheck pm.max_children and MySQL's max_connections after any traffic growth — settings tuned for last year's traffic are a common hidden cause of load spikes

Load average is one of the oldest metrics in Unix, and it's still one of the fastest ways to get an honest read on whether a server is keeping up — as long as you remember to check it against your core count, not against a number that felt scary in isolation.

Frequently Asked Questions

What's a "normal" load average for a VPS?

There's no universal number — it's relative to your core count. As a rule of thumb, a load average at or below your number of cores means the system is keeping up; well above it, especially sustained across all three time windows, means work is queuing.

Why is load average high but CPU usage shows low percentage?

Load average counts processes waiting on disk I/O, not just CPU time. High load with low CPU usage almost always points to a disk or I/O bottleneck — check %wa in top and confirm with vmstat.

Does a high 1-minute number mean I need to act immediately?

Not necessarily. A short spike that's already dropping in the 1-minute reading while the 5 and 15-minute numbers stay normal is usually a brief burst — a cron job, a backup, a traffic blip. Sustained highs across all three numbers are the ones worth investigating.

Can too little RAM cause high load average even if I have spare CPU cores?

Yes. When RAM runs out and the kernel starts swapping, processes end up waiting on slow disk I/O instead of running on the CPU, which drives load average up even though your cores technically have room. Check free -h for swap usage whenever load looks high with no obvious CPU cause.

Is it safe to just reboot the server when load average is high?

A reboot clears the symptom but not the cause — whatever was queuing processes (a slow query, a runaway script, undersized PHP-FPM limits) will come back the next time traffic or a cron job triggers it. Diagnose with ps aux --sort=-%cpu and the slow query log first, and treat a reboot as a temporary stopgap at best.