A process vanished, the site went down, and the logs say 'Killed'? Most likely the OOM Killer (Out Of Memory Killer) fired — a Linux kernel safety mechanism. When free memory runs out, the kernel keeps the system from freezing completely by forcibly killing the 'greediest' process. Let's see how to find what died, what ate the RAM, and how to tune the server so it doesn't happen again.
The OOM Killer fires on low RAM and kills the process with the highest oom_score (usually the one using the most memory). Look for traces in dmesg/journalctl; the fix is swap, memory limits or more server RAM.
What the OOM Killer is and why it kills processes
Linux lets processes reserve more memory than physically exists (overcommit). As long as they don't all use it at once, everything's fine. But when real usage hits the limit and swap is exhausted, the kernel must free memory immediately or the whole system freezes. That's when the OOM Killer steps in: it picks the process with the highest 'score' (oom_score) and terminates it.
How to find what got killed
- dmesg -T | grep -i -E 'killed process|out of memory' — shows the time and name of the killed process
- journalctl -k | grep -i 'out of memory' — the same from the kernel journal (with dates)
- Look for a line like 'Out of memory: Killed process 1234 (mysqld)' — the culprit's name is in parentheses
- grep -i oom /var/log/syslog — on systems where the kernel logs to syslog
How to find what's eating memory
- top or htop → sort by %MEM (press M in top) — see the top consumers
- ps aux --sort=-%mem | head — top processes by memory as a list
- free -h — how much RAM and swap is free right now
- Check a process's oom_score: cat /proc/<PID>/oom_score — the higher it is, the likelier it gets killed
OOM most often catches MySQL/MariaDB with a bloated buffer, PHP-FPM under load, Node.js with a memory leak and Java apps with no heap limit. Start your investigation there.
How to prevent a repeat
- Add swap (e.g. a 2–4 GB file) — a buffer for spikes so the kernel doesn't kill immediately
- Cap memory per service: MySQL — innodb_buffer_pool_size, PHP-FPM — pm.max_children, Node — --max-old-space-size
- Use systemd limits (MemoryMax=) or cgroups so one process can't eat everything
- Set up monitoring (free, your provider's monitoring) and alerts at 80% RAM
- If memory is consistently short — upgrade the VPS plan to your real needs
The OOM Killer is a symptom, not the disease. It says one thing: there isn't enough memory. The fix is either to fit the load into the RAM you have (limits, swap) or give it more RAM.
Tophosting editorial
When you need a bigger server
Swap and limits save you from occasional spikes, but if processes regularly hit the ceiling, that's a sign the plan is too small. Move the project to a VPS with RAM headroom: Vultr, 1Gbits or AdminVPS offer configs from 2 to 16+ GB with hourly billing, so you can raise memory to match the load without overpaying.
Bottom line
The OOM Killer isn't a bug but a kernel defense against a full freeze when memory runs out. The drill is simple: find the killed process in dmesg, identify the RAM hog via top/ps, then add swap, set limits or upgrade. If memory is always short, look at a bigger VPS — Vultr, 1Gbits or AdminVPS from our ranking.
