Linux OOM Killer 機制深度解析：原理、排查與核心進程保護實戰

當 Linux 系統記憶體耗盡時，核心會啟動 OOM Killer（Out-of-Memory Killer）機制，強制終止佔用記憶體過大的進程以維持系統存活。本文深入解析 OOM Killer 的觸發條件、分數計算機制、典型故障現象，並提供保護關鍵系統進程（如 SSH、監控代理）不被誤殺的實戰配置方法。

一、OOM Killer 核心機制

• 監控記憶體使用狀況，特別是瞬間大量佔用記憶體的進程
• 當可用記憶體低於閾值且無法透過回收釋放時觸發
• 根據演算法為每個進程計算 oom_score（0-1000），分數最高者優先被殺掉
• 即使無法釋放記憶體，也能重複執行確保核心記憶體處理流程不阻塞

二、典型故障現象

現象：SSH 突然無法連線，但 Ping 正常

• 機器可 Ping 通，排除網路故障與主機宕機
• 極大機率是 sshd 進程被 OOM Killer 終止
• 重啟後查看 /var/log/messages 會發現：Out of Memory: Kill process 247 (sshd)

其他可能造成同樣現象的原因

• 網路連線過多導致檔案描述符耗盡
• 使用 VIP 高可用方案時引發腦裂

三、OOM 分值計算與查看

每個進程的 OOM 分值可在 /proc//oom_score 查看。核心根據以下因素計算：

• 進程佔用的實體記憶體大小
• 進程類型（核心執行緒、使用者程式等）
• 進程擁有者權限（root 進程通常分值較低）
• oom_score_adj / oom_adj 調整值

四、保護關鍵進程不被 OOM Killer 終止

方法 1：設定 oom_score_adj 為最低值（推薦，Linux 2.6.36+）

echo -1000 > /proc//oom_score_adj

值範圍：-1000（完全禁用 OOM）到 1000（最優先被殺）。-1000 等同於關閉該進程的 OOM Killer。

方法 2：舊版內核使用 oom_adj（已棄用但仍相容）

echo -17 > /proc//oom_adj

值範圍：-17（禁用 OOM）到 15。注意：-17 為特殊值，表示完全不參與 OOM 殺戮。

實戰腳本：保護 SSH 服務

#!/bin/bash
# protect_sshd.sh - 每分鐘透過 cron 執行
pgrep -f "/usr/sbin/sshd" | while read PID; do
  echo -1000 > /proc/$PID/oom_score_adj
done

部署至 crontab：

* * * * * /path/to/protect_sshd.sh

可保護的關鍵進程建議清單

• sshd（遠端管理生命線）
• 監控代理（Zabbix Agent、Prometheus Node Exporter、Datadog Agent）
• 資料庫主進程（MySQL、PostgreSQL、Redis）
• 關鍵業務應用主進程
• 系統管理工具（salt-minion、ansible 等）

五、永久調整方案（系統層面）

1. 調整 /proc/sys/vm/panic_on_oom

echo 0 > /proc/sys/vm/panic_on_oom  # 不觸發 kernel panic，僅殺進程（預設）
echo 1 > /proc/sys/vm/panic_on_oom  # 觸發 kernel panic（嚴重環境可考慮）

2. 調整 /proc/sys/vm/oom_kill_allocating_task

echo 1 > /proc/sys/vm/oom_kill_allocating_task  # 直接殺發起分配請求的進程，不計算分值

3. 寫入 /etc/sysctl.conf 永久生效

vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0

六、排查建議

1. 確認是否為 OOM：grep -i "out of memory" /var/log/messages
2. 分析記憶體使用趨勢：sar -r、free -h、top
3. 找出記憶體洩漏進程：ps aux --sort=-%mem | head
4. 考慮增加 Swap 或實體記憶體
5. 優化應用程式記憶體使用（JVM Heap、資料庫緩衝區等）

理解並正確配置 OOM Killer，能在記憶體壓力下保障核心服務存活，是 Linux 系統穩定性建設的關鍵一環。