Guides

My server got slow: how to check RAM, CPU and disk

2 November 2026 6 min read

If your server has slowed down, look at three things: RAM, CPU and disk. Connect and run three commands: free -h for memory, top for the processor and df -h for the disk. Whichever one is full is the bottleneck. If all three look fine, the problem is usually in the application itself.

Start with the load

The load average is the average number of processes waiting for the CPU or the disk. The first three numbers in the output below are the averages over the last 1, 5 and 15 minutes. Compare them with your number of cores:

cat /proc/loadavg

nproc

If the load stays above the number of cores for a long time, the server can't keep up with its work.

RAM: free -h

free -h

The most important column is available. If it is very small and the Swap row is filling up, you are out of RAM. When memory runs out, the kernel kills one of the processes using the most memory (the OOM killer). A database or web application that closes on its own is often a sign of this. Check like this:

sudo dmesg -T | grep -i -E "out of memory|killed process"

CPU: top

top

On the screen that opens, the P key sorts processes by CPU use and the M key sorts them by memory use. Press q to quit. In the CPU line at the top, look at these:

us: the share of user processes. If it is high, an application is eating the CPU.
wa: time spent waiting for disk input and output. If it is high, the problem isn't the CPU but the disk.
st: time "stolen" from the virtual server, meaning time the virtualization layer gave the CPU to something else. If it stays high, the problem may not be inside your server. In that case, contact support.

Disk: df -h

df -h

df -i

The first command shows used space and the second shows the file count limit (inodes). When the disk is completely full, databases and applications can't write, and the server slows down or throws errors. Find out what is taking the space:

sudo du -xh / --max-depth=1 2>/dev/null | sort -h | tail -n 8

If system logs have grown, you can shrink them with sudo journalctl --vacuum-size=200M. If you use Docker, docker system df shows the space used by images and containers, and docker stats --no-stream shows how much CPU and memory each container uses.

Symptom, likely cause and fix

Symptom	Likely cause	What to do
Pages are slow now and then, available is low, swap is full	Not enough RAM	Shut down services you don't need and trim the application's memory settings (for example the PHP-FPM worker count or database memory). If that isn't enough, scale the server up.
A service closes by itself, "killed process" appears in the `dmesg` output	Memory ran out and the OOM killer stepped in	Add RAM or reduce memory use.
One process in `top` keeps a whole core fully busy	A stuck process, a faulty plugin or a loop	Find the process, then fix or disable the application or plugin behind it.
Load is high, the CPU is idle, wa is high	The disk is being waited on (heavy writes or swap)	Look at the si and so columns in `vmstat 1 5`. If swap is in use, add RAM.
`df -h` or `df -i` is full	Out of disk space or inodes	Clean up large files and logs. If it keeps filling up, scale up.
st stays high	The problem may be outside your server	Contact support.

At Seturack each server's disk speed is limited: a sustained 500 MB/s and 20,000 IOPS for reads, and 200 MB/s and 8,000 IOPS for writes. If your values in the iostat -x 1 5 output sit at these numbers, disk load is what is slowing you down. Reduce the work with caching or spread it over time. If iostat isn't there, install it with sudo apt install -y sysstat.

When does swap help?

Swap uses the disk in place of RAM. It lets the server ride out short memory spikes without the OOM killer, but it isn't as fast as RAM. If si and so in the vmstat 1 5 output stay above zero, the server is constantly writing to swap. The fix is RAM, not swap. If you have no swap (swapon --show prints nothing) and want to smooth out spikes, you can add a 2 GB swap file. These commands are for an ext4 file system:

sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile

sudo mkswap /swapfile && sudo swapon /swapfile

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

If the resources look fine

If RAM, CPU and disk look comfortable, check the name of the top process in top:

If php-fpm, apache2 or nginx is at the top, the problem is usually the site itself: a heavy plugin, missing caching or a sudden jump in visitors.
If mysqld or mariadbd is at the top, there are slow queries. Turn on the database's slow query log and see which queries take long.
If a process you don't recognize keeps eating the CPU, the server may have been compromised. Change your passwords, check open sessions and the output of sudo ss -tulpn, and reinstall the server with a clean system if needed.

When to scale up

The order is: tune first, add caching, switch off unneeded work. If the load is still high after that, scale the server up. In the panel, open the Size tab of your server, move the sliders to the new size and confirm. After payment, the server restarts once on its own and comes back at the new size. Your IP address and data stay the same, and you only pay the difference for the remaining days. You can grow RAM, vCores and disk separately, so you only raise what's running short. Scaling up grows the disk, while scaling down doesn't shrink it. For details, see the scaling article.

If the server doesn't respond at all because of the load, SSH may not connect. In that case, open the VNC Console from the panel, or restart the server from the panel.