MYSYSAD · Kernel Forensics

💀 OOM Killer Autopsy

Paste a raw dmesg Out-Of-Memory block to expose the crime scene: who ate your RAM, who died, and exactly how to prevent the next execution.

KERNEL OOM PARSER POSIX / Linux 3.x+ RSS PAGE AGGREGATOR

Raw OOM Log Input

Crime Scene — System State at Time of Kill

🔫 Trigger Process

—

💀 The Victim (Killed)

—

📊 Memory at Time of Kill

—

Suspects Line-Up — Aggregated Memory Consumption RSS × 4096 → MB · sorted by usage

Process RAM Usage MB oom_adj Badness

OOM Victim OOM Trigger Other Process

oom_score_adj ranges from -1000 (immune — never killed) to +1000 (highest kill priority). The kernel selects the process with the highest adjusted oom_score: badness = rss × (adj + 1000). A score of 0 is neutral. Services should set OOMScoreAdjust=-1000 in their systemd unit to be immune.

Annotated Kernel Log

Prevention & Hardening — Based on Your Incident

Protect the Victim with systemd

systemd / OOMScoreAdjust=-1000

Setting OOMScoreAdjust=-1000 makes the service completely immune to the OOM Killer. Use systemctl daemon-reload && systemctl restart <service> to apply. Verify with cat /proc/<pid>/oom_score_adj.

Kernel sysctl Tuning

sysctl / vm.overcommit & panic settings

vm.panic_on_oom=0: default — invoke OOM killer (don't panic). vm.overcommit_memory=2: strict mode — refuse allocations that exceed physical RAM + swap × ratio. Suitable for databases; may break applications relying on overcommit.

cgroup v2 Memory Limit

systemd / MemoryMax limit

MemoryMax hard-caps the cgroup's RSS. The process is OOM-killed inside its cgroup before the system-level OOM Killer ever fires. MemoryHigh throttles at a soft limit without killing. Use systemd-cgtop to monitor live cgroup memory.

Live Memory Diagnostics

Forensic commands to run after an OOM event

⚠️ IMPORTANT DISCLAIMER: Tools are provided "AS IS" for educational purposes only.

Review all commands before executing. By using this site you agree to our Terms of Service.