Diagnosing a slow server
“The server is slow” is a symptom with at least five unrelated causes. Here is how to find which one you have, in about ten minutes.
Start with load average, but read it correctly
uptime
Three numbers: the average number of processes running or waiting over one, five and fifteen minutes. On Linux this includes processes waiting on disk, which is why a machine with idle CPUs can show a load of 40. Compare it with your core count — a load of 8 on sixteen cores is fine; the same load on two cores is not.
The shape matters more than the value. Rising means it is getting worse; falling means you are looking at the aftermath.
Is it CPU?
top or htop, then look at the summary line.
- High us — your application is genuinely busy. Find the process.
- High sy — the kernel is busy, often on network or filesystem work.
- High wa — the CPUs are waiting on disk. Skip to the disk section; the processor is not your problem.
- High st — steal time, meaning a hypervisor is taking cycles. On a dedicated machine this should be zero, and if it is not, tell us.
Is it memory?
free -h
Ignore the cache figure; Linux uses free memory as cache and that is correct behaviour. The number that matters is available. If that is near zero and swap is being used continuously, the machine is thrashing and everything else you measure will be misleading.
Check whether the kernel has been killing processes:
dmesg -T | grep -i 'out of memory'
Is it disk?
iostat -x 2
Look at %util and the await columns. A device at 100% utilisation with
rising await is saturated. Then find who is doing it:
iotop -oPa
If one process is responsible, you have your answer. If everything is slow at once and the figures look bad across every device, check disk health — a drive going bad slows the whole array long before it fails outright.
Is it network?
ss -s for socket counts, and look for a large number in
TIME-WAIT or a backlog that is not draining.
ip -s link for errors and drops on the interface. A non-zero and
growing error count is a hardware or cabling matter and therefore ours.
If throughput rather than the machine is the complaint, that is a different investigation: speed testing and routing problems.
The thing everyone forgets
Check whether anything changed. journalctl --since '2 hours ago', your
deployment history, your package manager log. The overwhelming majority of
“suddenly slow” servers became slow because something was deployed,
updated or enabled — not because the hardware quietly degraded.
When to involve us
If the numbers point below your operating system — interface errors, steal time on a dedicated machine, disk latency with no process responsible, sustained clocks far under specification — open a ticket with what you measured. Include the commands and the output. We will check it against what we see from our side, and if the hardware is at fault it is replaced.
If it points above the operating system, the fix is yours: we run unmanaged machines, as what unmanaged means explains. We will still tell you what we would look at next.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base