Diagnose a slow or overloaded VPS

A slow server is short of one of three things: CPU, memory, or disk. Each leaves a different trace, and the fix for one does nothing for the others. Find out which it is before changing anything.

Everything below works on Ubuntu, Debian, AlmaLinux, and Rocky. One package needs installing, noted where it comes up.

1. Take the three readings

Start with load, memory, and a five second sample of what the kernel is doing:

$ nproc
$ uptime
$ free -h
$ vmstat 1 5

nproc prints how many vCPUs you have. uptime ends with three load averages, for the last 1, 5, and 15 minutes. vmstat 1 5 prints five lines one second apart; ignore the first, which is the average since boot.

2. CPU: compare load to vCPU count

Load average is the number of processes that wanted to run and either got a CPU or waited for one. On Linux it also counts processes waiting for disk, which matters in section 4.

The number only means something next to your vCPU count. A load of 3 is fine on 4 vCPUs and a problem on 1. If the 15 minute figure is above nproc, that suggests sustained contention over roughly the last quarter of an hour.

Confirm it is CPU and not disk with the vmstat output. The r column is the number of runnable processes: either running or waiting for CPU time. The us and sy columns are the percentage of CPU time spent running your programs and the kernel. High r, high us, low wa: you are short of CPU.

Then look at the st column, steal time: time your vCPU wanted to run but the physical host was busy elsewhere. On a healthy host it stays near zero. If it is steadily above a few percent while your own load is low, the cause is outside your server. Open a ticket with the vmstat output attached.

3. Memory: the available column

$ free -h

The free column misleads. Linux uses spare memory for file cache and gives it back the moment a program needs it. The number that matters is available, in the last column. When it drops near zero, the server is short of memory.

Two vmstat columns confirm it. si and so are memory being swapped in and out per second. On a server with no swap they stay at zero and the kernel kills a process instead, which our guide on adding swap to your VPS covers. On a server with swap, steady non-zero numbers in both columns mean the server is constantly moving memory to disk and back, and each of those moves is a slow disk read.

4. Disk: watch the wa column

The wa column in vmstat is the share of time the CPU sat idle because a process was waiting for the disk. A few percent during a backup is normal. Sustained double digits while the site is slow means the disk is the bottleneck, and the load average will be high even though us and sy are low, because those waiting processes count toward load.

For the detail, install sysstat, which brings iostat:

$ sudo apt install -y sysstat

$ sudo dnf install -y sysstat

$ iostat -xy 1 5

-x adds the extended columns, -y skips the since-boot average. Read r_await and w_await: the average time in milliseconds a read or write took, including time spent queued. On the NVMe storage our plans use, single digit values are normal. Tens of milliseconds, sustained, means something is keeping the disk busy.

Ignore %util on NVMe. The iostat manual notes it only indicates saturation for devices that handle one request at a time, and NVMe does not.

5. Find the process

Once you know which resource is short, find who is using it:

$ top

Press P to sort by CPU, M to sort by memory, and 1 to see each vCPU on its own line. The %Cpu(s) line at the top shows the same us, sy, wa, and st figures as vmstat, so you can watch them change as you act.

For disk, top does not show which process is responsible. pidstat does, and it came with sysstat:

$ pidstat -d 1 5

The kB_rd/s and kB_wr/s columns show each process's disk reads and writes per second.

6. Decide: tune it or upgrade it

If one process is the cause and should not be using that much, fix the process: a database doing full table scans, a PHP pool with too many workers, a runaway cron job.

If the server is doing more work than it has capacity for, tuning will not get it back. Three signs it is time for a bigger plan:

• Load stays above nproc at normal traffic, with st near zero
• available memory sits under 10 percent of total, with swap in steady use
• wa is high with nothing unusual running

The client area shows the same story over days instead of seconds, and our guide on reading your VPS usage graphs explains what a healthy week looks like. When it is time to move up, how much RAM and CPU your VPS needs matches workloads to plans.

Quick reference

Where to go next

If the server is down, start with my website is down: what to check first. If memory is the shortage, add swap first, so the next spike slows the server instead of killing a process.