How to Check CPU, RAM, Disk, and Inode Usage on an Ubuntu VPS

# How to Check CPU, RAM, Disk, and Inode Usage on an Ubuntu VPS Use this article to perform a quick resource check on an Ubuntu VPS and identify common causes of website slowdowns, errors, or downtime. ## Requirements - SSH access to the VPS - A user with `sudo` privileges for system-wide checks - The server's SSH address and login credentials - Basic familiarity with running commands Run commands carefully. Do not delete files until you have confirmed which service created them and whether they are required. ## Step 1: Check disk space Run: ```bash df -h ``` Check the filesystem mounted at `/`. Review the `Use%` value. As a general warning point, investigate sustained usage above 80 percent. Do not wait until the filesystem reaches 100 percent. To locate large directories: ```bash sudo du -xhd1 / 2>/dev/null | sort -h ``` If `/var` is large, run: ```bash sudo du -xhd1 /var 2>/dev/null | sort -h ``` Check common locations such as `/var/log`, website directories, database directories, backup folders, and temporary storage. ## Step 2: Check inode usage Run: ```bash df -i ``` Review the `IUse%` value for `/`. If inode usage is high, find directories containing many files: ```bash sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -n | tail -20 ``` Common causes include cache files, PHP sessions, mail messages, temporary files, image thumbnails, and failed backup jobs. ## Step 3: Check RAM and swap Run: ```bash free -h ``` Use the `available` memory value as the main quick indicator. Occasional Linux filesystem cache usage is normal. To view memory-consuming processes: ```bash top ``` Press `M` to sort by memory usage. Press `q` to exit. Check for recent out-of-memory events: ```bash sudo journalctl -k | grep -i -E 'out of memory|oom|killed process' ``` If available memory remains low or processes are repeatedly killed, review application and database limits before increasing resources. ## Step 4: Check CPU and load Run: ```bash uptime ``` Then open the live process view: ```bash top ``` Press `P` to sort by CPU usage. Check the number of available CPU threads: ```bash nproc ``` A load average that remains higher than the available CPU count may indicate CPU contention or tasks waiting on storage. Investigate sustained load rather than a short spike. Record the process name and command using the most CPU before restarting services. ## Step 5: Check log growth List the sizes of log directories and files: ```bash sudo du -sh /var/log/* 2>/dev/null | sort -h ``` If the server uses `systemd-journald`, check journal usage: ```bash sudo journalctl --disk-usage ``` View recent warnings from the current boot: ```bash sudo journalctl -p warning -b ``` If one application is repeatedly writing errors, fix the underlying application or service problem. Do not simply delete logs and ignore the cause. ## Step 6: Run a combined health check Use this command for a quick summary: ```bash printf '\nDisk:\n'; df -h /; printf '\nInodes:\n'; df -i /; printf '\nMemory:\n'; free -h; printf '\nLoad:\n'; uptime ``` Save the output during normal operation. Comparing normal output with incident output helps identify which resource changed. ## Verification A basic check is complete when you have confirmed: - The root filesystem is not close to full. - Inode usage is not close to 100 percent. - Available memory is stable. - Swap is not continually increasing. - CPU load is not persistently excessive. - No unexpected process is consuming resources. - Logs and backups are not growing without control. For ongoing protection, configure monitoring alerts for disk, inode, RAM, CPU, load, and service availability. Test each alert so you know notifications are delivered. ## Troubleshooting ### The disk is full but `du` does not show the missing space A deleted file may still be held open by a running process. Check open deleted files with: ```bash sudo lsof +L1 ``` Restart the responsible service during an appropriate maintenance window, or follow the service's documented log-reopen procedure. ### Disk space is available but applications cannot create files Check inode usage with `df -i`. If inodes are exhausted, locate and safely remove unnecessary small files or correct the application cleanup process. ### RAM appears almost full Check `free -h` and focus on `available`, not only `used`. Linux may be using memory for cache. Investigate if available memory is low, swap activity is sustained, or processes are being killed. ### CPU usage is high but no single process appears responsible Check load average, I/O wait, scheduled jobs, containers, database activity, and the process list again during the incident. High load can result from storage waits rather than CPU computation alone. ### Log files keep growing Inspect the relevant service configuration and verify that `logrotate` is running. Also investigate repeated warnings or errors in the application log. Increasing storage only delays the problem if the error continues. ### The website is down after disk exhaustion First preserve any useful diagnostic information. Check filesystem usage, service status, web-server logs, database status, and recent kernel messages. Free only confirmed unnecessary data, then restart affected services if required. Review the cause before restoring normal traffic. ## Common mistakes - Monitoring only CPU and ignoring disk or inode usage - Treating a single CPU spike as proof of a permanent capacity problem - Deleting database files or application data without verification - Removing active logs manually without checking log rotation - Storing unlimited backups on the same VPS - Assuming free disk space means files can always be created - Increasing VPS resources without identifying the process causing abnormal usage - Disabling security or monitoring tools because they consume some resources - Using `rm -rf` on an uncertain path ## When to review the VPS size Consider a resource increase or a different hosting configuration when normal workload usage repeatedly approaches safe thresholds after cleanup and tuning. Review CPU, RAM, storage, inode count, database requirements, backups, and expected traffic together. A small website may not need a VPS at all; shared or WordPress hosting can be more practical when server administration is not required. A VPS is more appropriate when the application needs root-level control, custom software, background workers, or more predictable resources. For migration or hosting changes, prepare a backup and use a documented [website migration procedure](/knowledgebase/website-migration).