How to Monitor VPS Performance: CPU, RAM, Disk, and Network

Overview

VPS monitoring means keeping an eye on your server’s core resources: CPU usage, memory, disk I/O, and network throughput. If your site is slow, your app is crashing, or you’re getting out-of-memory errors, the answer is almost always hiding in one of those four areas.

Most users only check performance after something goes wrong. The smarter approach is setting up basic monitoring from day one, so you have a baseline to compare against when things go sideways. A server that’s sitting at 90% CPU load at 3am is a problem you want to catch before your customers do.

This article covers both command-line tools for immediate diagnosis and longer-term monitoring options. Whether you’re on a VPS SSD Hosting plan or managing a fleet of servers, the fundamentals here apply.

Prerequisites

• SSH access to your VPS (root or sudo user)
• A Linux-based VPS running Ubuntu 20.04/22.04/24.04, Debian 11/12, AlmaLinux 8/9, or CentOS Stream 9
• Basic comfort with the command line — you don’t need to be a sysadmin, but you’ll be running commands
• Optional: a monitoring tool account if you plan to set up alerting (covered in Step 5)

Step-by-Step: Monitoring Your VPS Performance

Step 1: Check Real-Time CPU and Memory Usage with top or htop

The fastest way to see what’s eating your resources is top, which comes pre-installed on every Linux distro. SSH into your VPS and run:

top

You’ll see a live-updating table of processes sorted by CPU usage. The header shows overall CPU percentages, total vs. used memory, and swap usage. Press M to sort by memory instead, or Q to quit.

If you want something more readable, install htop:

# Ubuntu/Debian
apt install htop -y

# AlmaLinux/CentOS Stream
dnf install htop -y

# Run it
htop

htop gives you colour-coded bars for each CPU core and memory, plus the ability to kill processes directly. I’d recommend it over plain top for day-to-day use.

📝 Note: High CPU from a process called kswapd0 almost always means your VPS is running out of RAM and swapping to disk aggressively. That’s a memory problem, not a CPU problem — don’t just add a bigger CPU plan without checking RAM first.

Step 2: Check Disk Usage and I/O

Disk space and disk speed are two separate things. Check space first:

df -h

This shows all mounted filesystems with human-readable sizes. Pay attention to the Use% column. If your root partition (/) is above 85%, you’re in danger territory — many services start behaving oddly or failing entirely at 95%+.

To check what’s actually consuming space:

du -sh /* 2>/dev/null | sort -rh | head -20

This ranks the top 20 directories by size. Bloated /var/log directories are a very common culprit, especially on servers running cPanel or busy mail services.

For disk I/O (read/write speed in real time), use iostat from the sysstat package:

# Install sysstat
apt install sysstat -y   # Debian/Ubuntu
dnf install sysstat -y   # AlmaLinux/CentOS

# Run iostat — refresh every 2 seconds
iostat -xz 2

Watch the %util column for each disk device. If a device is consistently above 80-90% utilised, your storage is a bottleneck. On an SSD-backed VPS this is less common, but it does happen under heavy database load.

Step 3: Monitor Network Traffic

To see live network usage per interface, use nload or iftop:

# Install and run nload
apt install nload -y
nload eth0

Replace eth0 with your actual interface name. If you’re not sure what it’s called, run ip a to list all interfaces — on newer systems it might be ens3, ens18, or similar.

For a breakdown of which connections are consuming the most bandwidth:

apt install iftop -y
iftop -i eth0

⚠ Warning: If you see unexpected outbound traffic spikes to unfamiliar IPs, don’t ignore it. It can indicate a compromised service or a script sending spam. Check your process list and outbound firewall rules immediately.

Step 4: Review System Logs for Performance-Related Errors

Raw metrics tell you something is wrong. Logs tell you why. Check the system journal for errors in the last hour:

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

For OOM (out-of-memory) killer events specifically — this is where Linux starts forcibly killing processes because RAM ran out:

dmesg | grep -i "oom|killed process"

OOM kills are one of the most common causes of unexplained service restarts on VPS plans with 1-2GB RAM. If you see these regularly, you either need more memory or you need to tune the memory limits on your heaviest processes (MySQL’s innodb_buffer_pool_size is a frequent offender).

Step 5: Set Up Ongoing Monitoring with Netdata or Prometheus

Running commands manually is fine for a quick check, but you need historical data to spot trends. I’d recommend Netdata for most VPS users — it’s lightweight, installs in one command, and gives you a web dashboard with 1-second metric resolution:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
bash /tmp/netdata-kickstart.sh

Once installed, Netdata runs on port 19999 by default. Access it at http://YOUR_VPS_IP:19999. Make sure port 19999 is open in your firewall, or set up an Nginx reverse proxy if you want it accessible over HTTPS.

📝 Note: Netdata stores metrics in RAM by default, so it won’t persist after a reboot unless you configure a database backend. For basic monitoring, this is fine — you’re using it to watch live trends, not audit months of history.

For more complex setups (multiple servers, long-term retention, alerting to Slack or PagerDuty), look at the Prometheus + Grafana stack. It’s a heavier install but gives you far more flexibility.

Common Issues and Troubleshooting

High CPU Usage with No Obvious Process

You open htop and CPU is pegged at 90%+, but no single process stands out. This often means many small processes are running, or a process is spawning and dying too quickly to catch in a snapshot. Run this to sample the top CPU consumers over 5 seconds:

ps aux --sort=-%cpu | head -15

Also check for runaway cron jobs: grep -r '' /etc/cron* /var/spool/cron/. A misconfigured cron task looping every minute is surprisingly common.

VPS Feels Slow But CPU and RAM Look Fine

This is almost always disk I/O wait. In top, look at the wa value in the CPU line (e.g., %Cpu(s): 2.1 us, 0.5 sy, 0.0 ni, 80.2 id, 17.1 wa). Anything above 5-10% I/O wait means your processes are spending significant time waiting on disk. Run iostat -xz 2 to confirm which device is saturated.

Memory Usage Shows 100% but Server Isn’t Crashing

Linux intentionally uses free RAM for disk caching — it’s not wasted, it’s being useful. The number you actually care about is available memory, not free memory. Run:

free -h

Look at the available column in the Mem row. That’s the memory actually available for new processes. If that number is near zero, you have a real memory shortage. If it’s healthy, your server is fine.

Netdata Dashboard Not Loading on Port 19999

Almost always a firewall rule. If you’re using ufw:

ufw allow 19999/tcp
ufw reload

If you’re using firewalld (AlmaLinux/CentOS):

firewall-cmd --permanent --add-port=19999/tcp
firewall-cmd --reload

Also verify Netdata is actually running: systemctl status netdata

Disk Space Keeps Filling Up Unexpectedly

Nine times out of ten it’s logs. Check /var/log with du -sh /var/log/*. Also check for large core dump files: find / -name "core" -size +100M 2>/dev/null. On cPanel servers, mail queue files in /var/spool/exim can grow to gigabytes if something is stuck.

FAQ