Slow VPS or server lag? Find the bottleneck in 10 minutes
Is your VPS slow? First figure out what exactly is slow, then check four places: the CPU (load, one core at 100 % or steal time), the memory (full, swap or the OOM killer), the disk (iowait) and the network (ping and packet loss). With top, free, iostat and mtr you'll know within ten minutes which of the four is holding things back.
Install the tools beforehand, so you have them at hand when things go wrong:
sudo apt install htop sysstat mtr-tinyWant graphs over a longer period? Then Netdata shows per second what your VPS is doing. For a quick look, htop works too, as in checking the usage of your VPS.
VPS slow? First pin down what exactly is slow
"Slow" can mean three very different things, and each points somewhere else:
- Lag in a game: players snap back to an earlier spot, broken blocks reappear, vehicles stutter. Usually the server isn't hitting its ticks (CPU), or the connection is losing packets (network).
- A slow SSH session: letters appear with a delay. That points to the network, or to a VPS that's so maxed out that even your shell has to wait.
- A slow website: often the database or the disk, sometimes the memory.
Also look at the pattern. Is it always slow, only in the evening when everyone is online, or always around the same time? A fixed time often points to a scheduled task, such as your own backup script or a cron job. And is it one player complaining or everyone? If it's one player, it's usually down to their own connection.

CPU: load, one core at 100 % and steal time
Start with two numbers:
nproc
uptimenproc gives your number of vCores, uptime the load average over 1, 5 and 15 minutes. If the load stays above the number of vCores for a longer time, work is queuing up. Linux also counts processes waiting on the disk in that number, so then check in top what's going on. In top, press 1 to see each vCore separately. You'll then usually see one of three patterns:
- All cores maxed out, with high values for
usandsy: you don't have enough computing power, or a process is running away. Check inhtopwhich process is at the top. - One core at 100 %, the rest quiet: the classic game server problem. The main thread of Minecraft, FiveM or Valheim has hit its ceiling. More vCores won't help then, a faster core will. Why is explained in What is a vCPU (vCore)? and Ryzen vs EPYC for game servers.
- A high
st: steal time, the time the hypervisor made your vCore wait because the physical core was busy elsewhere. A few percent now and then is normal with shared vCores. Ifststays clearly high for a longer time while your server is slow, save the output ofvmstat 1 30and include it in a ticket; our support is happy to think along.
Memory: full, swap or the OOM killer
free -hLook at the available column, not at free. Linux uses unused memory as cache (buff/cache) and gives it back as soon as a program needs it, so a low free is normal. If available is close to zero, you really are full. Two signals confirm it:
- Swapping: in
vmstat 1, thesiandsocolumns keep staying above zero. Your VPS is shuffling memory to the disk and back, and you feel that everywhere. - The OOM killer: the kernel stops a process when memory runs out. Your game server then seems to crash without an error message. Check it with
sudo dmesg -T | grep -i -E 'out of memory|killed process'.
A common mistake with Java servers: setting -Xmx to the VPS's entire memory. Java uses more than just the heap and the operating system wants room too, so leave at least 1 GB free. If you run Minecraft with mods on less than 8 GB, more memory is simply the solution here.
Disk: iowait and scheduled tasks
In top, wa stands for the time the CPU waits for the disk to finish. If it's regularly high, look per disk:
iostat -x 1Watch r_await and w_await: the average time in milliseconds a read or write request takes, including waiting in the queue. On NVMe these should be low; if they climb sharply, a process is keeping the disk busy. The %util column says little on NVMe: according to the iostat manual, it doesn't show the limit of devices that handle requests in parallel. Which process is using the disk you can see with sudo iotop (package iotop).
Well-known culprits are your own backup script or a cron job that archives a whole world folder, a log file that grows unchecked and a database query without an index. Also check with df -h whether the disk isn't full: a full disk causes strange errors and freezes, long before you realise why.
Network: ping, mtr and packet loss
Measure from your own computer to the VPS:
ping -c 20 your-ip
mtr -rwc 100 your-ipOn Windows you use ping -n 20 your-ip; for mtr there's WinMTR. mtr sends 100 rounds of one second and shows the loss and delay per hop. Read it like this: loss at a hop that doesn't carry through to the last line usually comes from a router that gives pings low priority, and is harmless. Loss that carries through all the way to your VPS is real. If one player complains, also measure from the VPS to their IP address.
If all players stutter at the same time, first check status.mc-node.net to see whether something is up with the nodes. All VPSs are located in Hengelo; how the distance to your players determines the ping is covered in Server location and ping.
Game server specific: TPS, MSPT and hitches
A game server measures its own health, and those numbers are often clearer than top. A Minecraft server wants to hit 20 ticks per second, so at most 50 ms per tick (MSPT). If the MSPT climbs while one core is at 100 %, it's the CPU. If TPS and MSPT are fine but everyone lags, it's more likely the network. Per game:
- TPS, MSPT and lag: what the numbers really mean
- spark: find out which plugin, entity or chunk eats up the time
- Fixing FiveM server lag, for hitch warnings in the console and heavy scripts
- Palworld server: fixing lag and rubber-banding
When upgrading helps (and when it doesn't)
A bigger plan only solves the bottleneck you've found:
| What you see | Bottleneck | What helps |
|---|---|---|
available close to zero, swap or OOM messages | memory | a bigger plan within your line |
| one core at 100 %, high MSPT | speed per core | from KVM VPS to Premium VPS, or tackling heavy plugins and scripts |
| all cores maxed out | computing power | more vCores, or spreading the load |
persistently high st | shared cores | ticket with vmstat output, or a VDS with dedicated cores |
high wa and await | disk usage | find the task and move it; upgrading rarely helps |
| packet loss up to the last hop | network | check the status page, include mtr; upgrading doesn't help |
Within your line, you upgrade in the client area and pay the difference for the rest of your billing period. If your bottleneck is speed per core, the Premium VPS with Ryzen 9 is the logical step: an AMD Ryzen 9 9950X* with DDR5, up to 5.7 GHz compared with up to 4.0 GHz for the EPYC 7443P of the KVM VPS. If it's steal time, look at a VDS with dedicated cores. Switching between lines isn't a one-click job: expect a new VPS and a move. Not sure which line fits? Read Which VPS should you choose?
* or AMD Ryzen 9 7950X3D, depending on the node.
Frequently asked questions
Why is my VPS slow?
Usually because of one of four bottlenecks: the CPU (one core at 100 % or steal time), the memory (full or swapping), the disk (lots of iowait from a process or a full disk) or the network (packet loss). With top, free -h, iostat -x 1 and mtr you'll see within ten minutes which one it is. A game server with lag often has a CPU bottleneck in the main thread.
What is steal time and is it bad?
Steal time (st in top) is the time your vCore wanted to compute, but the hypervisor gave the physical core to another VPS. A few percent now and then is normal with shared vCores. If it stays high for a longer time while your server is slow, include the output of vmstat 1 30 in a ticket, or choose a VDS with dedicated cores.
Does more RAM help against lag?
Only if the memory is really full: available in free -h is close to zero, your VPS is swapping or the OOM killer is stopping processes. Lag caused by a main thread stuck on one core won't be fixed by more RAM; then a faster core helps, or fewer heavy plugins and scripts.
How can I tell if there's an outage?
Check status.mc-node.net; it shows the live status of the nodes. If nothing shows up there and only your server is stuttering, look for the cause with top, free, iostat and mtr. Include the output of mtr from your own computer when you open a ticket.