Why Is the Server Slow? Load, CPU, Memory & Disk

In one line

A slow server is short of CPU, memory, disk I/O, or network, or it's waiting on something else. A 60-second checklist of standard commands tells you which, before you guess.

0/5 · 0%

Think of it like this

A traffic jam. Before widening the road, you check whether the problem is too many cars (load), a broken-down lorry (one hot process), roadworks (slow disk), or the car park at the destination being full (memory). Each has a different fix.

Key ideas

01
LOAD AVERAGE (uptime: 1, 5, 15-minute averages) counts processes running OR waiting to run, AND those stuck in uninterruptible I/O wait. Compare it with the number of CPUs (nproc): a load of 8 on an 8-core machine is busy but OK; 30 means queueing. High load with low CPU usage usually means DISK waits.
02
CPU: top/htop sorted by CPU; %us (your code), %sy (kernel), %wa (waiting for I/O), %st (STEAL: the hypervisor is giving your VM's CPU to others, common on burstable cloud instances that ran out of credits). mpstat -P ALL 1 shows whether one core is pegged (a single-threaded bottleneck).
03
MEMORY: free -h: look at AVAILABLE, not 'free' (Linux uses spare RAM as page cache, which is good). Swapping (vmstat 1: si/so columns non-zero) makes everything crawl. The OOM KILLER chooses a process to kill when memory runs out: dmesg -T | grep -i 'killed process' shows who died.
04
DISK: iostat -xz 1: %util near 100% and a high r_await/w_await mean the disk is saturated; df -h and df -i for full disks (Topic 7.5); iotop shows which process does the I/O. On cloud disks, check provisioned IOPS/throughput limits and burst credits.
05
The famous '60-second analysis' (Brendan Gregg): uptime, dmesg -T | tail, vmstat 1, mpstat -P ALL 1, pidstat 1, iostat -xz 1, free -m, sar -n DEV 1, sar -n TCP,ETCP 1, top. Ten commands, one minute, and you know which resource is saturated (the USE method: Utilisation, Saturation, Errors).

Code & diagrams

the 60-second checklistbash

uptime                    # load vs nproc
dmesg -T | tail           # OOM kills, disk errors, network drops
vmstat 1 5                # r (run queue), si/so (swap), wa (I/O wait), st (steal)
mpstat -P ALL 1 3         # one core pegged?
pidstat 1 3               # which processes use the CPU
iostat -xz 1 3            # %util, await per disk
free -h                   # 'available' memory
sar -n DEV 1 3            # network throughput per interface
sar -n TCP,ETCP 1 3       # retransmits = network trouble
top                       # confirm the culprit

reading the symptomsdiagram

Rendering diagram…

Explain it without notes

Why can load average be high while CPU usage is low?

Why is 'free' memory near zero usually not a problem on Linux?

Practice

vmstat 1 shows r = 25 on a 4-vCPU VM, us 20%, st 60%. What's happening and what do you do?

Trade-offs

↔
Adding resources hides the symptom; finding the saturated resource (and why) often reveals a cheaper fix: an index, a cache, a leak, or a bad instance type.

Done when you can

I can run the 60-second checklist and interpret each command
I can tell CPU, memory, disk, and steal problems apart