On a VPS nobody tells you a resource is running low. There is no panel warning and no email. The first sign is usually a service that stopped or a site that became slow. Knowing four commands turns that from a mystery into a two-minute answer.
The four commands
top # what is using CPU and memory right now free -h # memory, and whether it is swapping df -h # disk usage per filesystem journalctl -xe # recent system log, including kills
Run df -h first when anything is wrong. A full disk takes down web server, database and mail simultaneously, and none of the resulting errors mention disk, so it is both the cheapest check and the one that explains the most confusing failures.
Reading memory correctly
free -h shows a large amount "used" on a healthy Linux system, because the kernel uses spare memory for disk cache. That is not a problem and reclaiming it is automatic.
The number to watch is available. If that is small and swap is being used steadily, the machine is short of memory, and the symptom is a server that feels unusably slow rather than merely busy.
Sustained swapping on a small VPS is worse than it looks: disk is orders of magnitude slower than memory, so a swapping server can be less responsive than one under heavy CPU load.
When a process disappears
Check the system log for out-of-memory entries. A process terminated by the kernel did not fail; it was killed, so its own log shows nothing unusual, which is why this is so often misdiagnosed.
Restarting the service works until the next time. The actual fix is less memory pressure or more memory.
Set up alerting, because you will not be watching
Checking manually works for a week. After that it lapses, and the first sign of a problem becomes a customer telling you.
Two things worth having:
Disk alerts at 80%. Disk fills predictably (logs, backups, temporary files) and it is entirely preventable with warning.
An external uptime check. Monitoring that runs on the server cannot tell you the server is down. It has to come from outside.
What fills a disk
Four things, in order of likelihood: log files growing without rotation, backups written locally and never cleaned up, package caches, and database growth.
Only the last is genuine. The other three are waste, and clearing them is a permanent fix instead of a postponement: adding disk for a server filling with old logs schedules the same conversation for next month.
Find the largest directories rather than guessing:
du -sh /var/* | sort -h
Establish what normal looks like
Look at the numbers once while everything is working. Knowing that this server normally sits at 30% memory makes 70% meaningful; without that baseline, every number is just a number.
That five minutes is what makes the four commands above useful when something is actually wrong. Common VPS issues sets out the diagnostic order.
One column in these tools points at a problem outside your server entirely, and almost nobody reads it. Understanding Load Average and CPU Steal goes into it.
Finding what is using the disk, not the space
High wa in top says processes are waiting on storage. It does not say which ones.
iotop -oPa # only processes doing I/O, accumulated pidstat -d 2 5 # per-process read and write rates
The usual answers on a web server are a backup running at the wrong hour, a database doing a large scan because a query has no index, or a log being written to continuously by something that is erroring.
That last one is worth noticing as a fault in its own right rather than as a disk problem. A process writing thousands of identical lines a minute is telling you something, and it will also fill the disk eventually.
Which process is using the network
ss -tunp | head -20 nethogs # per-process bandwidth, if installed
Useful when bandwidth usage is high and the website's traffic does not explain it. Common findings: a backup transferring to a remote destination, an application polling an external service far too often, or an outbound connection that should not exist at all.
The last of those is the one to act on immediately. There is more on what to do next in securing your VPS.
Reading a single process properly
When one process is responsible, these three answer most questions about it:
ps -o pid,etime,rss,%cpu,cmd -p 12345 cat /proc/12345/status | grep -E 'VmRSS|Threads' ls -l /proc/12345/cwd /proc/12345/exe
etime tells you how long it has been running, which distinguishes a runaway process from one that started a minute ago. The working directory and executable path identify which site or application it belongs to on a machine serving several, frequently the missing piece when a process name alone is ambiguous.
A record beats a snapshot
Everything above shows the present. Most questions arrive afterwards: it was slow at nine this morning, what was happening?
Lightweight system accounting collects that continuously and costs almost nothing:
sar -u 1 5 # processor, now sar -r -f /var/log/sa/sa15 # memory, on the 15th
Installing it before you need it is the entire trick. A machine with no history can only be diagnosed while the problem is happening, which means waiting for it to recur.
Understanding load average and CPU steal covers interpreting what it records, including the column that indicates a problem outside your server entirely.
Separate the machine being busy from the machine waiting
A high load figure has two very different causes and the fix for one does nothing for the other.
vmstat 5 5
ps -eo state,pid,comm | awk '$1 ~ /^D/' | head
iostat -x 5 3 2>/dev/null | awk '/^[a-z]/ {print $1, $NF}'
Processes in uninterruptible sleep are waiting on storage rather than using the processor. A list full of them with idle processors means the disk is the constraint, and adding cores changes nothing.
The distinction decides the purchase. Processor bound work is helped by more cores or less work. Storage bound work is helped by faster storage, fewer writes, or caching that stops the read happening at all.
Find the query rather than the process
On most small servers the database is the largest consumer, and naming the process is not enough to act on.
mysql -e "SHOW FULL PROCESSLIST" | head -20 mysql -e "SELECT * FROM information_schema.INNODB_TRX\G" 2>/dev/null | head -20 grep -c . /var/log/mysql/slow.log 2>/dev/null
The process list during a slow period shows what is actually running and for how long. A query that has been running for minutes is either missing an index or scanning a table that has grown past the point where it can be scanned.
Turning on the slow query record for a day gives the list without needing to be watching at the right moment, which is the practical version of this. Managing databases on a VPS goes into what to do with what it reports.
Watch what happens under real load, not at rest
Every reading above is taken while you are looking, and the interesting moments are the ones you miss.
while true; do
printf '%s %s %s\n' "$(date +%H:%M:%S)" "$(cut -d' ' -f1 /proc/loadavg)" \
"$(free -m | awk '/Mem:/{print $3}')"
sleep 60
done >> ~/load.log &
A minute by minute record for a week costs almost nothing and answers questions no snapshot can: when the peak is, whether it correlates with traffic or with a scheduled job, and whether the machine recovers between peaks or never gets back to a baseline.
The last question is the important one. A machine that does not return to its resting state between busy periods is not coping, even when every individual reading looks acceptable.