Monitoring your VPS resources
Keep an eye on CPU, memory and disk before they become a problem -- the commands to check, what normal looks like, and what a spike is telling you.
A VPS keeps working right up until a resource runs out, and then it fails all at once -- a full disk stops logs and databases writing, memory exhaustion kills whatever process the kernel picks, and sustained high CPU makes everything on the server feel slow. Checking usage now, while nothing is wrong, gives you a baseline for what "normal" looks like so a real problem is obvious later.
1. Overall load, live
top is on every server; htop, if installed, is easier to read:
top
htop # if installed: sudo apt install -y htopWatch the load average (three numbers: 1, 5 and 15-minute averages) against your server's CPU count. A load of 4 on a 2-CPU server means work is queued and waiting; the same number on an 8-CPU server is unremarkable.
2. Memory
free -hRead the available column, not free -- Linux deliberately uses spare memory to cache disk reads, so a low free number with a healthy available one is normal, not a problem.
3. Disk space
df -hOnce a filesystem reaches 100%, writes fail outright -- for a database that usually means the service stops rather than degrades. If one is climbing, find what is using it:
du -sh /var/log/* | sort -rh | head
du -sh /var/* | sort -rh | headOld logs are the most common cause. A log rotation policy (logrotate, installed by default on Ubuntu) keeps this from creeping back once you have cleared it.
4. What a spike is telling you
- CPU pinned near 100% for minutes at a time -- find the process with
top(pressPto sort by CPU) before restarting anything; a runaway process restarted blind just restarts the runaway. - Memory climbing steadily over days, never falling back -- a common shape for a slow leak in a long-running application; a scheduled restart is a workaround, not a fix.
- Disk filling in a straight line -- almost always logs or a backup directory nobody is pruning.
Setting a baseline
Run the three commands above once, today, and note the numbers somewhere you will see them again. There is no universal "normal" -- a database server legitimately runs hotter on memory than a static site does. What matters is noticing when your own server moves away from its own usual range.
If usage is already climbing toward a limit and you are not sure why, open a ticket from dash.mypandos.io with the output of the commands above -- that is the fastest way for us to help diagnose it with you.