Server is slow: where to start

A five-minute diagnostic procedure: CPU, memory, disk, network — how to use a few commands to identify what exactly is bottlenecking and what to do next.

Updated August 23, 2026

“Everything is slow” isn’t a diagnosis. There are only four bottlenecks: CPU, memory, disk, and network. Below is a check order that points to one of them in five minutes.

Step 1: the big picture

uptime
free -h
df -h

Three commands immediately rule out half the options. If the average load is noticeably higher than the number of cores on your tier, there’s a queue — see Load average. available close to zero means memory. If the partition is 100% full, look no further — read Out of space.

Step 2: what exactly is the bottleneck

vmstat 2 5

Look at the averaged columns, all except the first row:

high us and sy, large r — CPU-bound;
high wa, large b — disk-bound;
non-zero si and so — swapping is happening, which means memory is running out;
high st — time taken by the hypervisor, this is an external cause, contact support.

Step 3: find the culprit

ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10
iotop -boPan 3 | head -20        # apt install iotop
ss -tn state established | wc -l

The live picture is easier to read in htop or btop. Watch for processes in the D state — they’re waiting on disk and driving up the load.

If the culprit is your application, the next question is about it: slow database queries, a missing index, too many workers, an infinite loop after a deploy. Correlate the moment the slowdown started with the log:

journalctl --since "1 hour ago" -p warning

Step 4: check the history

Open “Overview” in the panel /hosting/vds/m/<id> and look at the graphs for the last day and week. Three typical patterns:

a step up at a specific moment — something changed: a deploy, an update, a new cron job;
a regular peak on a schedule — a background task; move it to the night or limit it with nice and ionice;
a flat plateau for weeks — you’ve simply outgrown your tier.

What to do with the finding

Bottleneck	Quick action	Long-term solution
CPU	find and stop the extra process	a tier with more cores
Memory	limit workers and database buffers, add swap	a tier with more memory
Disk	limit backups with `ionice`, trim logs	a higher tier: the plateau grows with the number of cores
Network	limit background downloads with `--bwlimit`	investigate the traffic source

The disk plateau is calculated as follows: 60 MB/s of writes per core, no lower than 60 and no higher than 400, with reads twice as high. If you’re consistently at the plateau, the disk won’t get faster without moving up — see Benchmark.

Common mistakes

Rebooting the machine right away. A reboot wipes the picture, and in an hour everything will repeat. Collect the numbers first.
Trusting a single frame. A spike the moment you start htop means nothing — watch for a minute.
Treating full memory as a problem. Look at available and swap, not free.
Changing your tier without figuring it out. A memory leak or a looping script will move to the new tier along with you. Downgrading back is not supported.

If CPU, memory, and disk are calm but the application is slow, the bottleneck is outside the machine: a slow external API, DNS, or the client’s network. Check curl -w '%{time_total}\n' -o /dev/null -s to the address you need.