top is where everyone starts and where most people stop. But the most common "the server is slow and top looks fine" incidents are invisible to top's default view. Here's the rest of the stack.
I/O wait — the slowdown top hides
wa is the percentage of time the CPU sat idle waiting for disk. 68% means two-thirds of your "CPU time" is the processor twiddling its thumbs waiting for I/O. top's load average looks high, but the CPU isn't the bottleneck — the disk is. The b column (processes blocked on I/O) confirms it.
Confirm at the device level
await is average latency per I/O in milliseconds. Healthy SSD await is single digits. 180ms means the disk is saturated — likely a runaway writer or a failing drive. %util near 100% confirms saturation.
CPU steal — the noisy-neighbour tax
The st column is steal time — CPU cycles your VM wanted but the hypervisor gave to another tenant:
If st is consistently high on a cloud VM, your instance is being starved by co-tenants. No amount of in-guest tuning fixes it — you resize or move.
Memory pressure vs swap usage
People panic at any swap usage. That's wrong. The question is whether you're actively swapping:
si/so (swap in/out) near zero with swap used is fine — the kernel parked idle pages. so continuously above zero means you're thrashing, and that's the emergency.
The decision tree
| Symptom | Look at | Cause |
|---|---|---|
| High load, low CPU | wa in vmstat | I/O bottleneck |
| High load on cloud VM | st | noisy neighbour |
| Slow despite free RAM | si/so | active swapping |
| One core pinned | top then -1 | single-threaded hog |
top tells you something is wrong. vmstat and iostat tell you what.