Linux OOM Killer Fix: Proven Ways to Stop Costly DB Crashes

A database process that vanishes during a traffic spike can look like an application crash, especially when the MySQL or PostgreSQL log has no clear explanation. A Linux OOM killer fix starts by confirming who stopped the process and which memory limit was reached. It should not begin with a blind reboot or a copied sysctl setting.

The Linux kernel can terminate a process when memory cannot be reclaimed, but the event may be global, limited to a container or systemd service, or caused by a user-space service such as systemd-oomd. The same symptom can also come from a database error, service manager, container restart, or host failure. This guide shows how to distinguish those cases and make a measured correction.

Is your production database down now? Preserve the kernel and service logs before restarting. OS Assistance offers Emergency Incident Triage ($199 initial member option). Check current eligibility and response terms at checkout; triage does not promise a repair completion time.

Linux OOM Killer Fix: Confirm what actually stopped the database

Start with the kernel journal around the time of the incident. Run this as a user with permission to read system logs:

journalctl -k --since "2 hours ago" --no-pager |
  grep -Ei 'out of memory|oom-kill|killed process|memory cgroup'

Look for messages naming the victim process, such as mysqld or postgres, and details about memory use or a cgroup. If the journal does not retain the event, check the ring buffer and your distribution’s system logs:

dmesg -T | grep -Ei 'out of memory|oom-kill|killed process'
journalctl --since "2 hours ago" --no-pager | grep -Ei 'oom|killed process'

A kernel message that says a process was killed is strong evidence of an OOM event. No message does not rule one out: logs may have rotated, the process may have been stopped by a container limit, or a userspace monitor may have acted first. Check the database and service logs at the same timestamps rather than assuming every unexpected exit was the kernel OOM killer. This confirmation is the first part of a safe Linux OOM killer fix: establish the event and its scope before changing settings.

On systems running systemd-oomd, inspect its journal too:

systemctl status systemd-oomd
journalctl -u systemd-oomd --since "2 hours ago" --no-pager

systemd-oomd uses cgroup v2 and memory-pressure information to act before a kernel OOM event. It is a separate path to investigate, not proof that the kernel selected the database process.

Check the service or container memory limit

A database may be the largest process on the host and still be killed because its service, container, pod, or virtual machine has a smaller memory limit than the machine. For a systemd service, identify the actual unit name first; names differ across Ubuntu, Debian, RHEL, Rocky Linux, and MariaDB/MySQL packages. A Linux OOM killer fix should first establish whether the memory budget was exhausted on the whole host or inside a smaller service boundary.

systemctl list-units --type=service | grep -Ei 'mysql|maria|postgres'
systemctl show mariadb.service -p ControlGroup --value

For a cgroup v2 service, use the reported control-group path to inspect its memory event counters and limit. Replace the example unit and path with the values from your server:

cat /sys/fs/cgroup/system.slice/mariadb.service/memory.events
cat /sys/fs/cgroup/system.slice/mariadb.service/memory.max

An increasing oom_kill counter or a finite memory.max can point to a cgroup-level limit. Container runtimes and Kubernetes also report OOM state in their own tools; check the container or pod status and its configured limit. A host with available RAM can still have a workload that has exhausted its assigned cgroup memory. If the counter is rising, a Linux OOM killer fix may need a service or container limit change rather than a host-wide memory setting.

Measure memory pressure and find the trigger

Capture current memory and swap state before changing configuration. During an active incident, sample more than once so you can see whether memory pressure is getting worse:

free -h
vmstat 1 10
ps -eo pid,ppid,comm,rss,%mem --sort=-rss | head -n 20
cat /proc/pressure/memory

In vmstat, watch sustained swap-in and swap-out activity, not just the amount of swap currently used. Memory pressure information in /proc/pressure/memory is available on kernels that support PSI. Compare the sample with a normal baseline and with the timestamps in the application, database, and kernel logs. For a reliable Linux OOM killer fix, compare these samples with the host’s memory profile at normal load.

Look for more than the database: PHP-FPM or application workers, backup and compression jobs, analytics, monitoring agents, batch imports, caches, and other services all use the same host or cgroup budget. The process that triggered allocation pressure may not be the process that the OOM killer selected. A useful Linux OOM killer fix addresses the workload or limit that caused the shortage, not just the victim name in the log.

Size MySQL and PostgreSQL memory from workload evidence

Do not copy fixed buffer-pool, connection, or work-memory values from another server. First record the host’s usable RAM, other services on it, the database’s peak concurrency, and its configuration. The database may use memory through shared buffers, per-connection work, query operations, caches, background workers, and the operating system.

MySQL and MariaDB checks

Review the InnoDB buffer pool and connection activity alongside host memory. The buffer pool can be the largest database allocation, but it must leave room for the operating system and other processes:

mysql -e "SHOW GLOBAL VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections');"
mysql -e "SHOW GLOBAL STATUS WHERE Variable_name IN ('Threads_connected','Max_used_connections');"

A Linux OOM killer fix for MySQL should start from this measured peak, since the buffer pool and concurrent query work share memory with the rest of the host. Use observed peak connections and query behavior to decide whether the configured connection ceiling is reasonable. Per-connection memory is not all necessarily allocated at login, and query operations can allocate more memory as they run. Lowering max_connections or the buffer pool without checking application demand can create a different outage.

PostgreSQL checks

Review shared buffers, connection counts, parallel work, and per-operation memory together:

sudo -u postgres psql -c "SHOW shared_buffers;"
sudo -u postgres psql -c "SHOW work_mem;"
sudo -u postgres psql -c "SHOW max_connections;"
sudo -u postgres psql -c "SELECT count(*) FROM pg_stat_activity;"

PostgreSQL’s work_mem applies to query operations such as sorts and hash tables. A query can use more than one such operation, and multiple sessions or parallel workers can run them at once. Budgeting only one work_mem allocation per connection can significantly understate peak use. A safe Linux OOM killer fix sizes these settings against measured concurrency and the RAM left for the operating system and other services.

Apply a Linux OOM Killer Fix without risky blanket tuning

Once you have evidence, choose the smallest change that addresses the cause. Depending on what the logs and metrics show, that may mean reducing uncontrolled application-worker concurrency, correcting a memory leak, scheduling a backup away from peak traffic, adding host memory, adjusting a container limit, or revising database memory and connection settings. Make one change at a time, keep the previous values, and schedule restarts needed to apply database settings. When application workers or scheduled jobs drive the spike, the Linux OOM killer fix belongs in the workload schedule or concurrency limit as well as database settings.

oom_score_adj changes how the kernel ranks eligible processes for OOM selection. It does not create memory or correct an undersized cgroup. Setting a database to -1000 can prevent it from being selected by that OOM killer, but may leave the kernel to kill other important workloads instead. Do not use it as a default database-protection command; evaluate the service’s failure policy and test the complete workload first.

Likewise, do not set vm.overcommit_memory=2, a particular vm.overcommit_ratio, or a low vm.swappiness value as a universal fix. Strict overcommit changes whether memory commitments are accepted and can cause applications to receive allocation errors. Swappiness expresses the kernel’s relative preference between reclaiming anonymous memory and filesystem cache; it is not a direct “disable swap” switch. Check existing values and the kernel documentation, then change them only when the workload and application requirements justify it. For some incidents, the right Linux OOM killer fix is to keep kernel defaults and correct the application or service limit instead:

sysctl vm.overcommit_memory vm.overcommit_ratio vm.overcommit_kbytes vm.swappiness
grep -E 'MemAvailable|SwapTotal|SwapFree|CommitLimit|Committed_AS' /proc/meminfo
swapon --show

Swap can provide additional backing for memory, but heavy swapping may make a database unusably slow. Its size and storage should match the workload, recovery needs, and provider design; a fixed 4 GB NVMe swap file is not a universal requirement. A Linux OOM killer fix may include a deliberate swap change, but only after checking whether swap pressure is actually part of the incident.

Validate the change and watch for recurrence

After the planned change, verify database service health, application queries, kernel logs, cgroup event counters, memory pressure, and swap movement during representative traffic. Confirm backups are current and that database recovery completed cleanly. If the server is clustered, check replication lag and failover health before closing the incident. A Linux OOM killer fix is not verified until a representative workload no longer produces sustained pressure or a new OOM event.

• Alert on available memory, memory pressure, swap-in/swap-out activity, and OOM events.
• Track cgroup memory limits and OOM counters for containers and systemd services.
• Monitor database connections, query concurrency, background jobs, and application-worker counts together.
• Record the before-and-after settings, evidence, test results, and rollback plan.

A repeatable Linux OOM killer fix is an evidence-based operating change, not a promise that a single setting prevents every future memory event.

Related Linux troubleshooting guides

Memory exhaustion can overlap with other production symptoms. Use the matching guide when evidence points to a separate issue:

• Recover safely when a Linux server reaches 100% disk space.
• Troubleshoot Nginx 502 errors and PHP-FPM socket exhaustion.
• Diagnose high I/O wait and Linux storage bottlenecks.

OS Assistance Linux support options

For an active outage or recurring production workload, OS Assistance offers several ways to engage Linux support. Per-server plans remain separate from the unlimited-server Linux Care plan.

Service	Price	Scope
Membership + Monitoring	$25/server/month	Monitoring and membership for an approved server; incident work is separate.
Server Care	$59/server/month	Membership + Monitoring with scheduled maintenance.
Member incident support	$65/hour	Hourly incident work for a server with an active monthly plan.
Non-member incident support	$95/hour	Hourly support for a server without an active monthly plan.
Emergency Incident Triage	$199 initial member option	Priority triage for an active incident; confirm eligibility and response terms at checkout.
Linux Care	$4,000/month	Unlimited approved Linux servers, one active workstream at a time, and a plan shared within 24 hours during weekday service hours. Complex work may span multiple business days.

For a live database outage, contact OS Assistance or use the Emergency Incident Triage option. To discuss recurring server operations, ask whether Linux Care fits your environment.

Frequently asked questions

What does the Linux OOM killer do?

When memory cannot be reclaimed to satisfy an allocation, Linux may select a process to terminate. The selection can be limited by a memory cgroup, cpuset, or other policy, so check the applicable scope before changing host-wide settings. That is why a safe Linux OOM killer fix starts by identifying the exhausted memory scope.

Why did the OOM killer choose MySQL or PostgreSQL?

The database may have had a high OOM badness score or been the only eligible process within the exhausted memory scope. That does not prove the database initiated the pressure. Review the full kernel record, cgroup limits, and workload around the event.

Does setting oom_score_adj to -1000 fix a database OOM?

No. It changes the process’s OOM-selection preference but does not add memory or remove a cgroup limit. Protecting one process can shift the impact to other services, so use it only after a deliberate failure-policy review.

Should I set vm.overcommit_memory to 2 on a database server?

Not automatically. Mode 2 applies strict commit accounting and can reject memory commitments. Check the application’s allocation behavior and calculate the impact in a test environment before considering a production change.

Will adding swap prevent another database crash?

It may provide additional memory backing, but it cannot repair a leak, unsafe concurrency, or an undersized container limit. Monitor swap activity and database latency; sustained swapping can severely degrade performance.

Can Linux Care help with recurring database and server issues?

Linux Care covers unlimited approved Linux servers for $4,000 per month, with one active workstream at a time. Requests are triaged and planned within 24 hours during weekday service hours; complex work can take multiple business days.

Technical references

• Linux kernel documentation: virtual memory sysctl settings
• Linux kernel documentation: overcommit accounting
• Linux man-pages: process OOM score adjustment
• Linux kernel documentation: cgroup v2 memory events and limits
• systemd-oomd service documentation
• PostgreSQL documentation: resource consumption
• MySQL 8.4 documentation: InnoDB buffer pool