uptime prints three numbers after "load average", and they are the first thing an experienced admin looks at when a server is slow. They are also widely misread. Here is what they mean, what a healthy number is for your server, and what to look at next.
The three numbers
uptime
# 14:02:11 up 41 days, 3:12, 1 user, load average: 2.14, 1.80, 1.22Averages over the last 1, 5 and 15 minutes of the number of processes that are running or waiting to run — plus, on Linux, processes waiting on disk I/O. Roughly: how many things want the CPU right now.
The number only means something relative to the core count:
nproc
# 4On 4 cores, a load of 4.0 means every core is busy with nothing queued; 2.0 is half used; 8.0 means as many processes are waiting as running. Rules of thumb:
- Below core count: fine.
- Around core count sustained: the server is at capacity; time to look at what is using it.
- Well above core count: requests are queuing; users notice.
Trend matters: 1-minute high with 15-minute low is a spike; all three high is sustained pressure.
But load counts I/O wait too
On Linux, a process blocked waiting for a disk read also counts. So a load of 12 on 4 cores could be CPU saturation — or four PHP processes and eight waiting for a slow disk. Distinguish them with top.
Reading top
topThe header lines:
%Cpu(s): 62.0 us, 8.1 sy, 0.0 ni, 22.4 id, 7.1 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 7951.2 total, 412.0 free, 5120.4 used, 2418.8 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 2503.1 avail Mem- us — user CPU: your application (PHP, MySQL). High is normal under load.
- sy — kernel. High sustained is unusual; often networking or a runaway process.
- wa — I/O wait. Over 10% sustained means the disk is the bottleneck.
- st — steal: the hypervisor is giving your VPS less CPU than it wants. Over 5% sustained means a noisy neighbour or an oversold host — worth a ticket.
- id — idle.
- avail Mem — the number that matters for memory; free is misleading because Linux uses spare RAM as cache.
Below the header, processes sorted by CPU. Press M to sort by memory, P back to CPU, 1 to show each core, c to see full commands, q to quit.
htop
sudo apt install htop -y && htopThe same data with colour bars per core, a memory bar that separates cache from used, and a process tree (F5). F6 sorts, F4 filters by name (type php to see only PHP workers), F9 kills. It is the tool to leave open in a second terminal while you reproduce a slowdown.
Diagnosing by pattern
High us, load ≈ cores, wa low — CPU-bound. Find the process (top, sorted by CPU). PHP workers: too many, or a slow plugin; MySQL: a bad query — see the slow query log. Fix the code or the query, add caching, or add cores.
High wa, load high, us low — disk-bound. iostat -x 2 (from sysstat) shows utilisation per device; iotop shows which process. Usual causes: a backup running, MySQL with too small a buffer pool reading from disk, swapping. Check free -m and vmstat 1 for si/so.
avail Mem near zero, swap in use, load spiky — memory pressure. Everything gets slow because the kernel is swapping. ps aux --sort=-%mem | head finds the consumers; usually too many PHP-FPM workers (sizing them) or an oversized buffer pool.
High st — not your server's fault. Move, or ask the provider.
Load high, CPU idle, nothing obvious — processes stuck in uninterruptible sleep (state D in ps), usually a hung NFS mount or a failing disk. ps -eo state,pid,cmd | grep '^D'.
Keep a baseline
The numbers are only useful against what normal looks like. Once a month, note the typical load and memory at peak. When a ticket says "the site is slow", the first question is whether the numbers differ from the baseline — and that takes ten seconds if you have one.
VPSPioneer managed VPS plans graph load, CPU breakdown, memory and disk I/O continuously and alert us on deviation, so "the site is slow" arrives with the cause already on a chart. The systematic version of this article — for when the pattern is not obvious — is troubleshooting a slow server step by step.