How to Check Server Resource Usage With top, htop, free and df

These commands show what is using a Linux server's resources: top or htop for CPU, load and processes; free -h for memory; df -h and df -i for disk space and inodes; du to find large folders; iostat and iotop for disk I/O; and ss for network connections. Run them over SSH when a server feels slow, and compare the results with what is normal for that server.

Examples use Ubuntu/Debian package names; on AlmaLinux and Rocky Linux use dnf install instead of apt install.

CPU, load and processes: top and htop

top

• The first line shows load average (1, 5 and 15 minutes). Compare it with the number of CPUs (nproc).
• The %Cpu(s) line shows how CPU time is split: us (applications), sy (kernel), wa (waiting for disk), st (stolen by the hypervisor on a VPS), id (idle).
• The process list shows what is busy. Press P to sort by CPU, M by memory, q to quit.

htop is a friendlier version with colour bars and mouse support:

sudo apt install htop
htop

Press F6 to choose the sort column and F4 to filter by name.

How to interpret these numbers is explained in Linux load average, CPU and memory explained.

Memory: free

free -h

Look at the available column, not "free". Linux uses spare memory as disk cache and gives it back when needed. Low available memory plus growing swap usage means memory pressure. Check for processes killed by the out-of-memory killer:

journalctl -k | grep -i "out of memory"

Disk space: df and du

df -h      # space per filesystem
df -i      # inodes (number of files)

If a filesystem is near 100%, find what is using space:

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

Common culprits: logs in /var/log, old backups, caches, uploaded files and database files. Delete or rotate carefully; never delete database files directly.

Disk I/O: iostat and iotop

sudo apt install sysstat iotop
iostat -x 2
sudo iotop -o

• In iostat, high %util and rising await values mean the disk is busy and requests are waiting.
• iotop -o shows only processes currently reading or writing.

High wa in top together with these numbers means storage is the bottleneck.

Network: ss and connection counts

ss -s                         # summary of connections
ss -tulpn                     # listening ports and the processes behind them
ss -tn state established | wc -l   # number of established TCP connections

To see which IP addresses make the most requests to your web server (adjust the log path for your server):

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

Services

systemctl --failed
systemctl status nginx mariadb php8.3-fpm   # adjust names to your stack

A quick health-check routine

1. uptime: is load higher than the CPU count?
2. free -h: is available memory low, swap growing?
3. df -h and df -i: any filesystem above about 85%?
4. top: which process uses the most CPU or memory?
5. iostat -x 2: is the disk saturated?
6. systemctl --failed: has anything stopped?
7. Recent logs: journalctl -p err --since "1 hour ago".

What to do with the findings is covered in troubleshooting a slow or unresponsive server.

Worked example: a slow WordPress VPS at lunchtime

Suppose a 2 vCPU, 4 GB VPS running a WooCommerce shop slows down every day around 1 pm. A typical investigation looks like this:

1. uptime shows load average: 6.80, 5.90, 3.10. With 2 vCPUs, a load of 6–7 means work is queuing, and the rising 1- and 5-minute values say the problem is happening now.
2. top, sorted by CPU (P), shows many php-fpm processes each using 20–40% CPU. wa is low (3%), so the disk is not the problem; the CPU is.
3. free -h shows 600 MB available and swap at 1.2 GB used and growing. Memory is also tight, probably because there are too many PHP workers for 4 GB.
4. The access log (awk command above) shows one IP address making thousands of requests to /?s= search URLs and product filters, which are not cached.
5. Action: block or rate-limit the abusive client, reduce pm.max_children so PHP workers fit in memory, and add caching rules. Load drops back below 2 within minutes.

The lesson: the commands narrowed the problem from "the server is slow" to "uncached requests from one bot are overloading PHP" in about ten minutes. Without the numbers, the obvious guess (buy a bigger server) would have cost money and not fixed the cause.

Saving a snapshot for later

When a problem is intermittent, capture the state while it happens so you can compare it with a normal moment:

{ date; uptime; free -h; df -h; top -b -n 1 | head -25; } > ~/snapshot-$(date +%H%M).txt

top -b -n 1 runs top once in batch mode, which is handy for scripts and for sharing with your hosting support team.

Frequently Asked Questions

Can I check resource usage on shared hosting?

You usually do not have root access, but cPanel's Resource Usage page shows your account's CPU, memory and process usage. See hosting resource limits explained.

Is there a graphical alternative?

Monitoring tools with dashboards keep history and alert you; see server monitoring basics. The commands above are best for live investigation.

Related reading

See what is a VPS. For a server you can inspect and tune yourself, compare the ServerNeed VPS plans.

Sources

• Linux man page: top(1)
• Linux man page: ss(8)
• sysstat documentation