A slow VPS almost always comes down to one of four things: CPU, memory, disk or network. This guide shows you how to work out which one, find what's using it, and decide whether to fix it yourself, upgrade your plan, or contact us.

It works on every operating system we offer: Ubuntu 22.04, 24.04 and 26.04, Debian 12 and 13, AlmaLinux 8, 9 and 10, and Rocky Linux 9 and 10.

Before you start

  • SSH access as root or as a user with sudo rights. If you're logged in as root, you can leave sudo off the commands.
  • If the server is so busy that SSH won't connect, click Open Console on your VPS's management page instead. See Use the web console to access your VPS.

The 5-minute check

Run these commands one at a time. The rest of this guide explains what to look for in each.

uptime                        # load average for the last 1, 5 and 15 minutes
nproc                         # how many vCPUs your VPS has
free -h                       # memory and swap
vmstat 1 5                    # CPU, swap and disk activity, once a second for 5 seconds
df -h                         # free disk space
df -i                         # free inodes (the number of files you can store)
ps aux --sort=-%cpu | head    # processes using the most CPU
ps aux --sort=-%mem | head    # processes using the most memory
sudo journalctl -k | grep -i "out of memory"    # processes killed for lack of memory

Step 1: Look at your graphs in the client area

On your VPS's management page, the Resources Graphs show CPU, memory and disk use, and the Network Graphs show traffic in and out. Switch between 24 Hours, 14 Days and 30 Days. A sudden jump usually means something changed, such as a traffic spike, an attack or a stuck process. A slow, steady climb usually means you're outgrowing your plan. See Manage your VPS from the client area.

Step 2: Compare the load average to your vCPUs

uptime shows something like load average: 3.95, 3.60, 2.10. That's roughly how many processes were running or waiting to run, on average, over the last 1, 5 and 15 minutes. Compare it to the number nproc shows:

  • Load below your vCPU count: the CPU is keeping up.
  • Load regularly above your vCPU count: processes are queuing for the CPU. For example, a load of 6 on a BOOST plan (2 vCPU) means things are waiting.

Load also counts processes waiting for the disk, so a high load while the CPU is mostly idle points to a disk problem (Step 5).

Step 3: Find the busy processes

Run top. Press P to sort by CPU, M to sort by memory, and q to quit. htop and btop show the same information in an easier layout: see Install htop to see what's running on your VPS and Install btop to monitor resources.

The CPU line near the top of top looks like this:

%Cpu(s): 12.0 us,  3.0 sy,  0.0 ni, 80.0 id,  4.5 wa,  0.0 hi,  0.5 si,  0.0 st
  • us and sy: time spent running your programs and the system. High values mean real CPU work.
  • id: idle time.
  • wa: time spent waiting for the disk (Step 5).
  • st: steal time (Step 4).

Step 4: Check for CPU steal

Steal is time your VPS wanted to use the CPU but had to wait for the physical server it runs on. To see it over a minute, run:

vmstat 5 12

Look at the st column. Small values now and then are normal. If steal stays high, for example above 10% for long periods while your own CPU use is modest, it's not something you can fix inside your VPS. Open a support ticket and include the vmstat 5 12 output, plus the date and time (NZ time) when you saw it.

Step 5: Check for disk I/O wait

A high wa value in top, or in the wa column of vmstat, means processes are waiting for the disk. A number in the b column of vmstat shows how many are blocked. To find which process is using the disk, install iotop:

Ubuntu/Debian

sudo apt install -y iotop
sudo iotop -o

AlmaLinux/Rocky

sudo dnf install -y iotop
sudo iotop -o

The -o option shows only processes that are reading or writing. On AlmaLinux and Rocky Linux 10 this installs a newer version called iotop-c; if iotop isn't found, run sudo iotop-c -o. Common causes are databases, backup jobs, heavy logging and swapping (Step 6). If I/O wait stays high but nothing much shows in iotop, open a support ticket with the details.

Step 6: Check memory, swap and the OOM killer

In free -h, look at the available column, not free. Linux uses spare memory as a disk cache, so a low "free" number is normal. If "available" is close to zero, you're short on memory.

Swap thrashing: in vmstat, the si and so columns show memory being swapped in from and out to disk. If they're above zero most of the time, the server is constantly swapping and everything slows down.

The OOM killer: when memory runs out completely, Linux kills a process to free some up. It often picks the biggest one, such as MySQL, MariaDB or your app, so it can look like a random crash. Check whether it's happened:

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

To fix memory problems, reduce what you're running (for example fewer PHP-FPM workers, or smaller MySQL buffers), fix apps that keep growing, or upgrade your plan. Swap can act as a safety net on small plans, but it's much slower than RAM. Check whether you have swap with swapon --show. To add some, see Add swap space to your VPS.

Step 7: Check for a full disk

In df -h, a disk at or near 100% can crash databases and break websites. df -i shows inodes: if IUse% is near 100%, you've run out of room for new files even if there's space left, usually because of huge numbers of small cache, session or mail files. To find the biggest folders:

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

Run it again on the biggest folder to dig deeper. Common space users are logs (shrink the system journal with sudo journalctl --vacuum-size=200M), old backups, package caches (sudo apt clean or sudo dnf clean all) and Docker images (check with docker system df).

Step 8: Check the network

Look at your Network Graphs for unusual spikes. On the server, ss -s shows a summary of connections. To see which IP addresses have the most connections to your websites:

ss -Htn state established '( sport = :80 or sport = :443 )' | awk '{sub(/:[^:]*$/, "", $4); print $4}' | sort | uniq -c | sort -rn | head

Your web server's access log shows who's been visiting. Change the path to suit your web server: /var/log/nginx/access.log for Nginx, /var/log/apache2/access.log for Apache on Ubuntu/Debian, or /var/log/httpd/access_log for Apache on AlmaLinux/Rocky:

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

If your server is quiet but the connection still seems slow, the problem may be on the network path between you and the server. Run mtr or traceroute to YOUR_SERVER_IP from your own computer, and include the results if you open a ticket.

Common culprits

  • Bot traffic: search crawlers, AI scrapers and password-guessing bots, often hitting wp-login.php or xmlrpc.php. Block the worst IP addresses in your firewall, or put your site behind a CDN such as Cloudflare.

    Ubuntu/Debian with UFW enabled:

    sudo ufw insert 1 deny from 203.0.113.10

    AlmaLinux/Rocky with firewalld:

    sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" reject'
sudo firewall-cmd --reload
    Replace 203.0.113.10 with the address you want to block, and take care not to block your own.
  • MySQL or MariaDB: slow or stuck queries can tie up CPU and disk. See what's running with sudo mysqladmin processlist, and make sure the database's memory settings fit your plan.
  • Runaway PHP or Node.js processes: dozens of PHP-FPM workers, or one Node.js app stuck at 100% CPU or using more and more memory. Restart the service or app, then check its logs to find the cause. Limit PHP-FPM workers with pm.max_children so they fit in your RAM.
  • Cron and backup jobs: if the server is slow at the same time every day or night, check scheduled jobs with crontab -l, sudo crontab -l, ls /etc/cron.d and systemctl list-timers. Move heavy jobs to quieter times.
  • Docker containers: run docker stats --no-stream to see CPU and memory use for each container. See Install Docker Engine and Docker Compose on your VPS.
  • Malware: an unfamiliar process using a lot of CPU, especially one with a random name or running from /tmp, may be a cryptocurrency miner. Treat the server as compromised: copy your data off, check it's clean, and reinstall.

Upgrade your plan, or open a ticket?

Upgrade your plan when your own software is steadily using most of your CPU or memory, your graphs show steady growth, or processes are still being killed for lack of memory after you've tuned things. Use Upgrade/Downgrade in the left-hand menu of your VPS's management page. For example, moving from EMBER (1 vCPU, 2 GB RAM) to BOOST (2 vCPU, 4 GB RAM) doubles both.

Open a support ticket when:

  • CPU steal stays high (Step 4).
  • I/O wait is high but nothing on your server is using the disk (Step 5).
  • The network is slow while your server is quiet (Step 8).
  • The VPS freezes, or Open Console doesn't respond either.

Tell us what you saw and when (date and time, NZ time), and paste the output of uptime, free -h and vmstat 5 12. Never include your passwords.

Related guides

Need help?

Our Cloud VPS plans are self-managed, so you're responsible for installing, securing and maintaining the software on your server. If something on our side isn't working, such as the network, or your VPS won't boot, open a support ticket. New to your VPS? Start with our Cloud VPS Getting Started Guide.

Was this answer helpful? 0 Users Found This Useful (0 Votes)

Most Popular Articles

Where are your servers located?

We run our VPS platform from two datacentres: Auckland, New Zealand: DataVault, in Grafton...
Cloud VPS Getting Started Guide

Welcome to your Hoopla Hosting Cloud VPS. This page is the best place to start. It explains...
Should I move to a VPS? Web hosting vs Managed cPanel VPS vs Cloud VPS

Most websites run happily on web hosting. But as a site gets busier, or you need software that...
Find your VPS login details and IP address

To connect to your new VPS, you need three things: its IP address, the username, and the...
Manage your VPS from the client area

Every Hoopla Hosting VPS comes with a management page in the client area. From there you can...