MySQL OOM 系列（二）：OOM Killer 評分算法、oom_score_adj 與進程生存博弈

前言

內存兌付失敗時，Linux 由 oom_kill_process() 選擇犧牲者。選擇依據是 oom_badness() 計算的分數（/proc//oom_score），分數越高越先死。本文逐行解讀內核源碼邏輯，實驗驗證 oom_score_adj（-1000~1000）對生存率的決定性影響，為 MySQL 免殺奠基。

一、oom_badness() 核心邏輯（kernel/fork.c）

points = p->mm->total_vm;                    // 1. 基礎分 = 進程物理頁數（RSS，不含 Swap）
points += 子進程獨立 mm 的 total_vm;         // 2. 累加子進程物理內存
points /= sqrt(cpu_time);                    // 3. CPU 時間長 → 分數降低（保護長運行進程）
points /= sqrt(sqrt(run_time));              // 4. 存活時間長 → 分數降低（保護系統服務）
if (task_nice(p) > 0) points *= 2;           // 5. 低優先級 → 分數翻倍
if (capable(CAP_SYS_ADMIN) || uid==0) points /= 4; // 6. root/特權進程 → 分數降低
if (capable(CAP_SYS_RAWIO)) points /= 4;     // 7. 直接硬件訪問 → 分數降低
points <<= oom_score_adj;                    // 8. 用戶態調控：左移 oom_score_adj 位（-1000~1000）

關鍵洞察：

• 基礎分與 RSS 正相關 → 內存大戶首當其衝
• oom_score_adj 為 指數級影響：+1000 必殺、-1000 免死金牌
• MySQL 典型特徵：大 RSS、長運行、root 權限、無 RAWIO → 基礎分高、保護因子有限

二、實驗驗證：oom_score_adj 生死線

環境

2GB RAM + 400MB Swap，啟動 3 個 1GB 申請+分級寫入進程

默認情況（adj=0）

第一個達到物理上限的進程被 Kill，oom_score=1000

設置 adj=15（最高風險）

echo 15 > /proc//oom_score_adj

該進程優先被 Kill，驗證指數級懲罰

設置 adj=-1000（免死金牌）

echo -1000 > /proc//oom_score_adj

進程存活，但系統可能因無可殺進程而崩潰（極端風險）

三、MySQL 為什麼容易被 Kill？

結論：MySQL 是教科書級的「高分候選者」。

四、禁用 OverCommit 可行嗎？

• overcommit_memory=2：MySQL 啟動申請 Buffer Pool 即失敗（申請 > CommitLimit），或運行中動態擴展失敗 → Crash
• 生產環境強烈不建議，會將「概率性 OOM Kill」轉為「確定性啟動失敗/運行時 Crash」

五、下一篇預告：MySQL 免殺三板斧

1. 合理規劃內存佔用（Buffer Pool 上限、連接內存上限）
2. 設置 oom_score_adj = -800（保留系統核心進程生存空間）
3. 建立內存水位監控 + 自動熔斷（Kill 閒置連接、限流）

1. 上一篇文章： MySQL OOM 系列（一）：Linux 內存過度提交機制與 OverCommit 深度解析
2. 下一篇文章： MySQL OOM 系列（三）：MySQL 免殺三板斧——內存規劃、oom_score_adj、監控熔斷

MySQL 綜合教學

MySQL 面試核心知識點全解析

MySQL 面試核心知識點全解析 1. 事務的 ACID

從小型到超大規模：MySQL 參考架構演進全景圖

Oracle 官方白皮書：四類業務、四級規模的拓撲指南 Or

MySQL 伺服器字元集設定失效問題：character_set_server 重啟後復原的解決方案

MySQL 伺服器字元集設定失效問題：character_s

MySQL 索引原理與實戰大全：B+Tree、覆蓋索引、最左前綴、全文索引、優化禁忌與驗證方法

索引基礎 索引是對列值排序的數據結構，提供指向數據行的邏輯指