OOM Killer on Linux: Why It Kills a Process, How to Stop It

What OOM Killer is and when it triggers

OOM Killer (Out Of Memory Killer) is a Linux kernel mechanism that forcibly terminates processes when RAM and swap run out at the same time. The kernel cannot let the system hang because of a memory shortage, so it picks a "victim" and kills it with SIGKILL. This most often happens on a VDS with 1-2 GB of RAM without configured swap, when MySQL, PHP-FPM, or a Java application suddenly spike their memory usage.

It is important to understand: OOM Killer is a protective mechanism, not a bug. If it triggered, the system genuinely ran out of memory, and the cause should be sought in your service configuration or in the amount of RAM.

How to confirm OOM Killer actually killed the process

If a service unexpectedly went down without a clear error in its own log, check the system journal:

journalctl -k | grep -i "out of memory"
dmesg | grep -i oom

The output will show a line like Out of memory: Killed process 1234 (mysqld) with the PID, process name, and the amount of memory occupied at the moment of the kill. This is the easiest way to distinguish OOM Killer from a process crashing for another reason, such as a segmentation fault.

How to find the process eating memory

Before setting up protection, find the actual memory consumer. A quick way is to sort processes by RAM usage:

ps aux --sort=-%mem | head -n 10
free -h

The free -h command shows total memory, used memory, free memory, and the swap size. Without swap, or with a small one, any load spike — a database backup, a traffic surge — instantly leads to OOM. For a detailed look at configuring swap, see the article on swap on a Linux VPS.

How the kernel picks a victim: oom_score

The kernel assigns every process an oom_score value — the higher it is, the more likely the process gets killed first. You can check the current score like this:

cat /proc/PID/oom_score

The score is affected by the amount of memory used, how long the process has been running, and an explicit oom_score_adj setting, which takes values from -1000 to 1000. A value of -1000 fully excludes a process from being killed, while 1000 makes it the first target.

How to protect an important process from OOM Killer

If your server runs a service that must never be killed under any circumstances, say the main database, lower its kill priority:

echo -900 > /proc/$(pidof mysqld)/oom_score_adj

This change lasts only until the process restarts. To make the setting permanent, add the parameter to the service's systemd unit file:

[Service]
OOMScoreAdjust=-900

After editing, run systemctl daemon-reload and restart the service. By protecting one process, you automatically raise the risk for the others — the kernel will still find someone to kill under a genuine memory shortage.

Prevention: swap, memory limits, and monitoring

A one-time oom_score_adj tweak does not solve a memory shortage — it just shifts the risk to another process. Real prevention looks like this:

• Set up a swap file of at least 1-2 GB to smooth out short-term load spikes.
• Explicitly limit memory for heavy services: memory_limit in PHP, innodb_buffer_pool_size in MySQL, -Xmx in Java.
• Connect RAM usage monitoring so you can see consumption rising before OOM triggers — see the article on VDS resource monitoring.
• Check the journal with journalctl -k after every incident — read more in the article on journalctl and rsyslog.
• Under a systemic memory shortage, the right step is to upgrade your VDS plan, not fight the symptoms.