Disk Full
Confirm which filesystem is actually full
df -hShows usage per mounted filesystem — confirm it's the filesystem you think it is; /var or /tmp filling up is more common than the root of a large data volume.
Find what's using the space
du -sh /var/log/* | sort -rh | head -10Lists the 10 largest items under a directory. Repeat one level deeper into whatever shows up largest.
Check for deleted-but-still-open files
If du and df disagree significantly — du reports far less used space than df — a process is very likely
holding a deleted file open, which keeps its space allocated until the process closes it or restarts.
lsof +L1Lists open files with a link count of zero — exactly this situation. Restarting the owning process (logrotate not reloading a service after rotation is a classic cause) releases the space.
Clean up safely
journalctl --vacuum-size=200MTrims the systemd journal down to a target size — a common and safe first place to reclaim space on a long-running host.
apt cleanClears the local package manager's download cache. Safe on Debian/Ubuntu, but confirm you're not about to reinstall from those cached .deb files on a host with no network access.
High CPU
Identify the process
topSort by CPU (default) and check the %CPU column against nproc — a single process above 100% is pegging at least one full core.
Check the load average against core count
uptimeThe three load averages (1/5/15 min) represent the average number of processes wanting CPU time. A load of 8 on a 4-core box means real contention; the same load on a 16-core box is nothing.
Narrow down what a specific process is doing
strace -c -p PIDSummarizes which system calls a running process is spending time in — useful for telling apart genuine CPU-bound work from a process spinning on I/O or a syscall in a tight loop.
High Memory
Check overall memory pressure
free -mCompare used against total, and check swap usage — meaningful swap use under load is a strong signal memory, not just usage, is actually the bottleneck.
Find the largest consumers
ps aux --sort=-%mem | head -10Lists processes sorted by memory usage, highest first.
Distinguish a leak from legitimate usage
Sample a suspect process's memory over time. Usage that climbs steadily and never comes back down under normal request patterns points at a leak; usage that tracks load and falls back down is probably just sized correctly for peak traffic.
The OOM killer
When the kernel can't free enough memory, it kills a process outright — check dmesg | grep -i 'out of memory' or
journalctl -k | grep -i oom after an unexplained process death with no application-level error at all.