Monitor RAM and CPU

A 512 MB or 2 GB VPS has less headroom than a dedicated server. Before adding resources, understand what consumes them: real memory use, reclaimable cache and CPU load relative to vCPU count. A naive reading of free or top often leads to the wrong conclusion.

Read memory

free -h
swapon --show
ps aux --sort=-%mem | head

In free, the important column is available, not free. buff/cache is made of pages the kernel can release under pressure: it is not lost memory. A server with 200 MB free but 1.2 GB available is not in trouble.

swapon --show tells whether swap is active. In a system container, swap is usually provided by the platform: you can see it without being able to resize it. Swap prevents a hard stop; it does not replace RAM.

Read CPU and load

uptime
nproc
top
vmstat 1 5

uptime shows three load averages (1, 5 and 15 minutes). Compare them to the vCPU count from nproc: a load of 2 on 2 vCPU means sustained saturation, a load of 2 on 4 vCPU still has headroom. High load can also come from disk waits, not only computation.

In top, watch us (user), sy (system), wa (I/O wait), id (idle) and st (time stolen by the platform). High wa points to the disk or a slow database. vmstat 1 5 confirms with r (runnable), b (blocked), si/so (swap in/out).

To rank processes:

ps aux --sort=-%cpu | head
sudo apt install sysstat
pidstat 1 5

Recognise the OOM killer

When memory runs out, the kernel kills a process. The service vanishes without a clear application message:

sudo journalctl -k | grep -i -E 'oom|killed process'
sudo dmesg -T | grep -i oom

Look for Out of memory: Killed process and the process name. Automatic restarts can hide the cause: the service comes back, then dies again. Reduce workers (PHP-FPM, Node.js, Python workers), database buffers, or move to a plan with more RAM.

Diagnose and fix

Work in this order:

1. Check available and swap.
2. Compare load to the vCPU count.
3. Identify the top processes by memory and CPU.
4. Look for an OOM in the kernel log.
5. Fix the cause before upgrading the plan.

A memory leak shows as a steady rise in a process RSS. Restarting the service daily is not a durable fix: measure, correct or cap it.

Verify

free -h
uptime
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
journalctl -k -b | grep -i oom

After a change, compare load and available memory at the same time of day over several days. A single sample proves nothing; the trend shows whether the VPS is correctly sized.