VPS Resource Monitoring with htop and iostat

Most VPS performance complaints — “my site is slow,” “the server keeps hanging” — come down to one of three resources maxing out: CPU, memory, or disk I/O. Your hosting panel’s usage graphs give you a rough daily average, but they won’t show you what’s happening right now, in real time, while a slow page is loading. That’s what htop and iostat are for, and both are free, lightweight, and installable on any Linux VPS in under a minute.

Installing Both Tools

On Ubuntu/Debian VPS instances, install with sudo apt update && sudo apt install htop sysstat. On CentOS/AlmaLinux/Rocky, use sudo yum install htop sysstat. htop installs directly; iostat is part of the sysstat package, not a standalone install — if a tutorial tells you to apt install iostat it’s out of date. After installing sysstat, enable data collection with sudo systemctl enable --now sysstat so iostat has historical data to draw on, not just a live snapshot.

Reading htop: CPU and Memory in Real Time

Run htop with no arguments and you get a live, color-coded view: per-core CPU bars at the top, a memory bar (green = used, blue = buffers/cache, yellow = swap), and a sortable process list below. Two things matter most on a VPS. First, the load average in the top-right corner — if the 1-minute load average is consistently above your VPS’s core count (e.g., above 2.0 on a 2-core plan), you’re CPU-bound and requests are queueing. Second, the memory bar’s green segment versus total — if green is pinned near the top and swap (usually shown separately) is climbing, you’re memory-starved, which on a WordPress VPS is almost always PHP-FPM workers or MySQL/MariaDB’s buffer pool sized too large for the available RAM.

Press F6 in htop to sort by a specific column (CPU%, MEM%) and instantly see which process is the actual offender — a runaway wp-cron job, a backup script that fired at the wrong time, or a single PHP-FPM worker stuck in a loop. Press F5 for tree view to see which parent process spawned it, useful when a plugin’s cron task is the real source of a spike.

Reading iostat: Disk I/O Bottlenecks

Run iostat -x 2 to get an extended report refreshing every 2 seconds — the -x flag is what adds the columns that actually matter. Two columns to watch: %util, which shows how saturated the disk device is (sustained values near 100% mean the disk itself, not CPU or RAM, is your bottleneck), and await, the average time in milliseconds a request waits for the disk to respond (under 10ms is healthy on SSD-backed VPS storage; sustained numbers in the hundreds indicate a genuinely overloaded or oversold disk, common on cheap shared-storage VPS plans).

This distinction matters because a slow site with low CPU and low memory usage but high disk await is a different problem than a slow site pegged on CPU — and it points to a different fix. High CPU means optimize code or upgrade vCPUs. High disk await, especially on a plan advertising “SSD” storage, often means the host is oversubscribing shared disk I/O across too many tenants, and no amount of caching-plugin tuning fixes that; it’s a hosting-plan problem.

A Practical Monitoring Routine

FAQ

Do these tools slow the server down while running?
No — both have negligible overhead, well under 1% CPU, and are safe to leave running in a terminal session during a live troubleshooting window.

What if I don’t have SSH access?
Some budget shared-hosting plans (as opposed to true VPS plans) don’t expose SSH at all, in which case you’re limited to whatever graphs the host’s panel provides. This is one of the practical differences between a VPS and shared hosting worth knowing before you buy.

My load average is high but htop shows no single process using much CPU — why?
Load average includes processes waiting on I/O, not just CPU-bound ones. If no process shows high CPU%, cross-check with iostat — you’re very likely I/O-bound, not CPU-bound, and htop alone won’t make that obvious.

The Verdict

htop and iostat together answer the question a hosting panel’s daily-average graph can’t: what’s happening on this server right now. Run them side by side during a real slow-page incident rather than guessing, and you’ll know within two minutes whether the fix is a code/config change you can make yourself or a hosting-plan limitation that requires upgrading or switching providers.