Users report a host is slow — diagnose the bottleneck from the metrics
Users report that an application on a Linux host has become slow. You have one snapshot of system metrics. Identify the bottleneck and name the next command you would run to confirm it. Reason from the figures — do not guess a single cause.
$ uptime
14:02:11 up 7 days, load average: 38.5, 22.1, 9.8
$ top (header)
%Cpu(s): 6.1 us, 3.0 sy, 0.0 ni, 4.0 id, 86.5 wa, 0.4 hi
MiB Mem : 15890 total, 9120 free, 3010 used, 3760 buff/cache
$ # 4 logical coresDiagnose the cause and state your next confirming command.
Load average 38 on 4 cores is far above capacity, yet CPU is mostly idle and 86.5% is wa (I/O wait), and memory is fine — so the host is disk-bound, not CPU-bound. The bottleneck is disk I/O: processes are blocked waiting on storage. Confirm with iotop or iostat -x to find the busy device and offending process.
- ✗Reading high load average as CPU saturation while ignoring the wa column
- ✗Misreading I/O wait (wa) as idle CPU rather than blocked-on-disk time
- ✗Stopping at the symptom instead of naming a command to find the busy device
- →How would
iostat -xcolumns like%utilandawaitconfirm a disk bottleneck? - →If wait were on the network instead, which tools would you reach for?
Walkthrough
Read every metric before committing to a cause.
run/wait queue — but load alone does not say what the tasks wait on.
number is 86.5 wa — I/O wait. The CPU is not the bottleneck; it is sitting idle waiting for I/O to complete.
pressure. Memory is ruled out.
- Load average 38.5 on 4 cores. Load far above the core count means a long
- CPU header. Only
6.1 us + 3.0 syis real work;4.0 idis idle. The giant - Memory.
9120 freeplus3760 buff/cacheof 15890 MiB — plenty free, no swap
So the host is disk-I/O-bound: processes are blocked in uninterruptible sleep on storage, which inflates load average while leaving the CPU idle.
Confirming commands:
iostat -x 1 5 # per-device %util and await — find the saturated disk
iotop -oPa # which process is doing the I/O
dmesg -T | tail # disk/controller errors, e.g. a failing driveA near-100% %util with high await on one device confirms the bottleneck; iotop names the offending process.
