Load average and top

Load average is the count of runnable tasks plus tasks stuck in uninterruptible sleep (D-state). It is not a CPU percentage. When your site feels slow, those three numbers from uptime tell you how long the queue has been busy, while top and vmstat show whether the wait is compute, disk, or something else.

Do not reboot in the first hour. Capture the numbers while the problem is still visible. A reboot can clear a backup, a cron stampede, or a heavy query, and then the load returns with nothing useful left in the journal for your ticket.

uptime; vmstat 1 5; ps aux –sort=-pcpu | head

uptime prints the 1-, 5-, and 15-minute load averages and how long the server has been up. Compare the 1-minute value to your vCPU count, not to a rule of thumb that “load 1 means the box is dying.” vmstat 1 5 gives five samples: r (runnable), b (blocked), then us, sy, wa, and st. High wa points at disk. High st points at the hypervisor. High us is real compute work. The sorted ps list names who is on the CPU, if anyone is. htop is easier to read, but the same numbers apply.

How to read load average against your CPUs

A load of 8 on two CPUs with iowait in the sixties is usually a disk story. Buying more cores only widens the queue; it does not shorten the wait for the drive. A load of 8 with CPU near five percent often means a lock, NFS delay, or a backup calling fsync. Match the load figure to runnable work and blocked work before you change the plan size.

A 15-minute load that stays high after the 1-minute number drops means you already missed the spike. That pattern usually points at a batch job, not a live crowd. Check JetBackup, a wp-cron storm, or a database dump. A high 1-minute load with a quiet 15-minute average is happening now, so run vmstat, then the process list, then make one careful change. Keep those two stories separate in one support ticket.

What to chase in the first hour

If wa is high, find the disk job: JetBackup, a mysqldump, a large media copy, or a full volume. If b is growing while CPU sits idle, you are still waiting, often on the same disk and sometimes on a lock. If us is high, look at PHP or MariaDB and the slow query before you shop for a larger SKU. If load spiked at 02:00 and you “fix” it at 14:00 by adding PHP workers, tomorrow night can get worse, not better.

On shared hosting, CloudLinux LVE limits can feel like the same pressure. The Metrics graph in cPanel will show when you hit the cap. More workers inside a capped LVE add contention rather than usable CPU. For the longer decision path on queue versus compute, see why load is not CPU. This page is the incident checklist: paste vmstat before you touch the pool.

Using top without guessing

Open top and watch the summary lines for load, CPU states, and memory. Sort by CPU or memory so the busy processes rise to the top. Confirm whether the hot process matches what vmstat already suggested. If nothing owns the CPU and wait stays high, stay on the disk path instead of restarting services at random.