How to Monitor Linux Server Resources Using top, htop, and Other Tools

Overview

Linux monitoring doesn’t require third-party dashboards or paid software. Every Linux server ships with built-in tools that show you exactly what’s happening with CPU, memory, disk I/O, and running processes in real time. Knowing how to read these tools is a core skill whether you’re on a shared VPS or a bare-metal dedicated server.

Most performance complaints — slow WordPress sites, unresponsive apps, failed cron jobs — trace back to resource exhaustion. CPU is pegged at 100%, memory is full and the server is swapping, or disk I/O is saturated. These tools tell you which one it is within seconds.

This article covers the most useful Linux monitoring commands for day-to-day server management: top, htop, vmstat, iostat, and df. You don’t need all of them — but you should know what each one is for.

Prerequisites

• SSH access to your Linux server (root or sudo user)
• A terminal client — Terminal on macOS/Linux, PuTTY or Windows Terminal on Windows
• Basic comfort with the command line (you don’t need to be an expert)
• htop is not installed by default on all distros — you may need to install it (covered below)
• This guide applies to Ubuntu 20.04+, Debian 11+, CentOS 7+, AlmaLinux 8/9, and Rocky Linux 8/9

Step-by-Step Instructions

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

top is installed on every Linux server by default. It gives you a live view of running processes sorted by CPU usage.

Connect via SSH and run:

top

The output refreshes every 3 seconds. Here’s what to look at first:

• %Cpu(s) row — us is user-space CPU (your apps), sy is kernel CPU, wa is I/O wait. If wa is above 10-15%, your disk is the bottleneck, not your CPU.
• MiB Mem row — shows total, free, used, and buff/cache memory. Don’t panic if “free” is near zero — Linux aggressively uses free RAM for cache, which is normal and healthy.
• MiB Swap row — if used swap is climbing, your server is out of real RAM. That’s the actual problem.
• The process list — sorted by CPU by default. Press M to sort by memory instead.

Press q to exit.

📝 Note: The “free memory” figure in top is misleading to beginners. Linux uses spare RAM for disk cache, so a server with 512 MB “free” out of 8 GB is not necessarily in trouble. Watch the Swap used figure instead — that’s the real warning sign.

Step 2: Install and Use htop for a Better View

htop is an improved, colour-coded version of top. It’s easier to read and lets you scroll, search, and kill processes interactively. I’d recommend it as your default monitoring tool for anything that isn’t a minimal container or embedded system.

Install it based on your distro:

# Ubuntu / Debian
apt install htop -y

# AlmaLinux / Rocky Linux / CentOS
dnf install htop -y

Then run it:

htop

Key things to know in htop:

• The coloured CPU bars at the top break down usage visually. Green is user processes, red is kernel, blue is low-priority tasks.
• Press F6 to change sort order — sort by MEM% when you’re debugging a memory leak.
• Press F4 to filter processes by name — useful when you want to find all php-fpm or mysql processes specifically.
• Press F9 to send a signal to a process (kill it). Use signal 15 first (graceful), then 9 only if it doesn’t respond.

⚠ Warning: Killing processes with signal 9 (SIGKILL) is a hard kill — the process gets no chance to clean up. For databases like MySQL or MariaDB, always try signal 15 first, or use systemctl stop mysql. A hard kill can leave InnoDB in an inconsistent state.

Step 3: Check Memory and Swap Usage with free

For a quick one-line memory snapshot without the process list:

free -h

The -h flag outputs human-readable values (GB/MB instead of kilobytes). The available column is the most useful — it estimates how much memory is actually free for new processes, accounting for reclaimable cache.

Step 4: Diagnose Disk I/O with iostat

iostat is part of the sysstat package. If your server is slow and CPU isn’t the culprit, check disk I/O next.

# Install sysstat if needed
apt install sysstat -y       # Debian/Ubuntu
dnf install sysstat -y       # AlmaLinux/Rocky

# Run iostat with 2-second refresh, extended stats
iostat -xz 2

Focus on the %util column. If it’s consistently above 80% for a device (e.g. sda or nvme0n1), that disk is saturated. On our VPS SSD Hosting plans, NVMe storage handles I/O far better than spinning disks, which matters a lot on database-heavy workloads.

📝 Note: await is the average time (in milliseconds) that I/O requests wait. Under 5ms is good. Over 20ms on an SSD is a red flag — could indicate filesystem issues, high queue depth, or a failing drive.

Step 5: Check Disk Space with df

Running out of disk space kills servers silently. Logs stop writing, databases crash, mail queues back up. Check it regularly.

df -h

Look at the Use% column. Anything above 85% needs attention. Above 95% is an emergency — some filesystems stop accepting writes before 100% because they reserve space for root.

To find what’s eating your disk space, du is your friend:

# Find the top 10 largest directories under /var
du -h /var --max-depth=2 | sort -rh | head -10

In my experience, /var/log and /var/lib/mysql are the most common culprits on a busy hosting server.

Step 6: Check System Load with vmstat

vmstat gives a compact view of CPU, memory, swap, I/O, and system activity in one line. It’s useful for spotting trends over time.

# Sample every 2 seconds, 10 times
vmstat 2 10

The columns to watch:

• r — processes waiting to run. If this is consistently higher than your CPU core count, you have a CPU bottleneck.
• si / so — swap in / swap out. Any non-zero value here means you’re swapping, which is slow.
• wa — CPU time spent waiting on I/O. Same as in top.

Common Issues and Troubleshooting

htop shows “command not found” after installation

On some minimal server images (common on cloud VPS builds), the PATH doesn’t include /usr/bin correctly for non-root users. Try running sudo htop or check the install with which htop. If it installed to /usr/bin/htop but still errors, your shell session may need refreshing — log out and back in.

CPU usage looks high but no single process is responsible

This usually means many small processes are each using a small amount. Sort by CPU in htop and watch for patterns — dozens of php-fpm workers or Apache httpd children each at 2-3% can add up to 80%+ total. This is a configuration issue, not a hardware issue. Review your PHP-FPM pool settings or Apache MaxRequestWorkers.

Server has free RAM but is still slow

Check swap first (free -h). If swap used is non-zero, the server was at some point out of RAM and started swapping. Even after RAM frees up, swap doesn’t automatically get cleared, so performance stays degraded. You can check this with vmstat 1 5 and watch the si/so columns. Restarting the heaviest services (e.g. MySQL) often clears swap without a full reboot.

df -h shows plenty of space but writes are failing

Check inode usage — it’s a separate limit from block space and it’s easy to hit on servers with large numbers of small files (email servers, cache directories).

df -i

If IUse% is at 100% on any filesystem, you’re out of inodes. You’ll need to delete files (especially small ones in tmp or cache directories) to recover. This doesn’t show up in regular df -h output, which trips up a lot of people.

Load average is high but CPU% in top looks normal

Load average counts both running and waiting (blocked on I/O) processes. A high load average with low CPU suggests an I/O bottleneck, not a compute one. Run iostat -xz 2 and check %util and await. This is an annoyingly common mismatch that confuses people who only watch the CPU graph.

FAQ