P1
OOM Killer Triggered — Linux Troubleshooting Guide
Diagnose memory pressure and OOM killer events on Linux. Covers identifying memory-hungry processes, leak detection, cache management, and service recovery.
15 min7 steps
Progress: 0/7 steps
0%
Get an overview of RAM and swap usage.
free -h && echo '---' && cat /proc/meminfo | head -5
Expected: Total, used, free, and available memory. 'available' is more useful than 'free' — it includes reclaimable cache.
Look for OOM kill events in system logs.
dmesg | grep -i 'oom\|out of memory\|killed process' | tail -10
Expected: If OOM was triggered, you'll see lines like 'Out of memory: Killed process PID (name)'.
Identify which processes are using the most RAM.
ps aux --sort=-%mem | head -15
Expected: Sorted by %MEM. The RSS column shows actual physical memory used in KB.
Look for processes whose memory usage has been growing over time.
ps -eo pid,user,rss,vsz,etime,comm --sort=-rss | head -15
Expected: Compare RSS (resident memory) with etime (elapsed time). A process running for days with very high RSS may have a leak.
If swap is heavily used, find which processes are swapping.
for pid in $(ls /proc/ | grep -E '^[0-9]+$'); do awk '/VmSwap/{print '$pid' " " $2 " kB"}' /proc/$pid/status 2>/dev/null; done | sort -k2 -rn | head -10Expected: Processes sorted by swap usage. Heavy swap usage causes severe performance degradation.
Drop filesystem caches to free memory. This is safe and non-destructive.
sync && echo 3 > /proc/sys/vm/drop_caches
Expected: Cached memory will be freed. Check with 'free -h' again.
This only frees cached/buffer memory that the kernel can reclaim anyway. It won't help if processes themselves are using too much RAM.
If a specific service is consuming excessive memory, restart it.
systemctl restart SERVICE_NAME
If the service is a database (MySQL, PostgreSQL), ensure no active transactions. Consider a graceful shutdown first.