Site icon New Generation Enterprise Linux

Finding what ate your memory before the OOM killer nuked it

Process & Resource Monitoring (Top/Htop/Ps/Systemd)

Finding what ate your memory before the OOM killer nuked it

🧩 The Challenge

Dealing with a server that keeps crashing in the middle of the night because of memory spikes is a special kind of hell. By the time I get a pager alert, the OOM killer has already wiped the evidence and everything looks perfectly normal again.

💡 The Fix

Check the systemd journal for the specific memory pressure events it captured right before the crash happened. It’ll tell you exactly which cgroup was hoarding RAM.

journalctl -u systemd-oomd --since "1 hour ago"

⚙️ Why It Works

Since most modern distros ship with systemd-oomd active, it keeps a detailed record of the exact moment it decided to start killing things to save the kernel. Searching the unit logs is way faster than digging through gigabytes of generic dmesg output.

🚀 Pro-Tip: Use journalctl -f -u systemd-oomd on a test box to watch it work in real-time when you trigger a fake memory bomb.

Linux Tips & Tricks | © ngelinux.com | 7/11/2026

0 0 votes
Article Rating
Exit mobile version