{"id":5107,"date":"2026-11-06T06:05:27","date_gmt":"2026-11-06T00:35:27","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/linux-out-of-memory-oom-killer-tuning-how-to-protect-mysql-and-web-servers-with-oomscoreadj\/"},"modified":"2026-11-06T06:05:27","modified_gmt":"2026-11-06T00:35:27","slug":"linux-out-of-memory-oom-killer-tuning-how-to-protect-mysql-and-web-servers-with-oomscoreadj","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/linux-out-of-memory-oom-killer-tuning-how-to-protect-mysql-and-web-servers-with-oomscoreadj\/","title":{"rendered":"Linux Out-of-Memory (OOM) Killer Tuning: How to Protect MySQL and Web Servers with oom_score_adj"},"content":{"rendered":"

Few events trigger more widespread outages in high-traffic web environments than an abrupt database crash caused by the Linux kernel Out-of-Memory (OOM) Killer. Under heavy concurrent query spikes or memory pressure from web workers, the kernel’s memory management subsystem evaluates running processes and ruthlessly invokes SIGKILL<\/code> against the largest memory consumer\u2014which is almost always your relational database engine. Whether you are staging microservices on CpanelFree<\/a> or orchestrating mission-critical bare-metal database instances, properly configuring oom_score_adj<\/code> alongside virtual memory sysctl policies is required to prevent catastrophic database downtime.<\/p>\n

<\/p>\n

How to Protect MySQL from OOM Killer Linux Environments: Step-by-Step Architecture<\/h2>\n
\n

Direct Answer:<\/strong> To protect MySQL from OOM killer Linux disruptions, set OOMScoreAdjust=-1000<\/code> in a systemd unit drop-in override (\/etc\/systemd\/system\/mysql.service.d\/override.conf<\/code>). This grants total immunity from kernel termination. Pair this setting with strict cgroups v2 memory boundaries, conservative virtual memory overcommit (vm.overcommit_memory = 2<\/code>), and dedicated swap space to guarantee rock-solid database availability.<\/p>\n<\/div>\n

The Linux kernel’s Out-of-Memory subsystem is an emergency safety mechanism designed to save the operating system from a hard freeze when physical RAM and configured swap space are completely exhausted. However, in production web hosting and database environments, its default heuristic algorithm frequently causes severe data corruption, abrupt transaction rollbacks, and lengthy InnoDB crash recovery cycles when it indiscriminately kills mysqld<\/code>, mariadbd<\/code>, or web server daemons instead of shedding transient, non-critical worker processes.<\/p>\n

The Core Mechanics of Linux OOM Scoring: Badness Heuristics<\/h3>\n

When the kernel memory allocator reaches a critical watermark and cannot reclaim pages through standard buffer eviction, page cache dropping, or swap paging, it invokes the function out_of_memory()<\/code> within the kernel source tree (mm\/oom_kill.c<\/code>). The kernel iterates across all active process descriptors in the system to calculate an integer badness score ranging from 0<\/code> to 1000<\/code> for each task. The process with the highest calculated badness score is selected as the victim and terminated immediately via an uncatchable SIGKILL<\/code> signal.<\/p>\n

The raw badness heuristic evaluates several key parameters:<\/p>\n