MySQL OOM 系列三：擺脫被 OOM Killer 終結的厄運

前言

前兩章分析了 Linux 記憶體過量分配策略與 OOM Killer 機制。MySQL 同樣受制於 OS 層面的過量分配控制（/proc/sys/vm/overcommit_memory），並非 MySQL 層面可控。若允許過量分配，innodb_buffer_pool_size 可遠超物理記憶體，但這部分空間未實際使用時不會觸發問題。

核心問題

1. 為什麼會記憶體不足？
2. 如何讓 MySQL 避免被 Kill？

記憶體不足的兩大成因

1. MySQL 自身記憶體規劃不當

Buffer Pool、連接緩衝、查詢緩存等配置總和超過可用記憶體。

2. 系統級「旁路」程式搶佔記憶體

監控腳本、定時任務、備份工具等在高峰期大量佔用記憶體，觸發 OOM Killer，MySQL 因佔用最大成為首選犧牲者。

三大降低風險策略

1) 合理規劃 MySQL 記憶體使用

• Buffer Pool 設為物理記憶體 60%-70%（專用 DB 服務器）
• 預留 20%-30% 給 OS、連接緩衝、排序緩衝、臨時表等
• 嚴格控制 max_connections，避免連接爆發導致記憶體耗盡

2) 調整 OOM Score Adj 降低被殺優先級

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

將 MySQL 進程設置為極難被殺（-17 為完全免疫，-15 為極低優先級）。需權衡：若系統極度缺記憶，MySQL 可能因無法分配記憶體而 Hang 住而非被殺。

3) 強化監控與報警，建立快速響應機制

• 監控關鍵指標：MemAvailable、SwapUsed、MySQL 進程 RSS
• 設置閾值告警（如可用記憶體 < 10% 或 Swap 使用 > 50%）
• DBA 接到告警後：優先 Kill 佔用記憶體大的非核心連接（KILL QUERY / KILL CONNECTION）

總結

受限於 Linux 過量分配機制，無法 100% 避免被殺，但通過「合理規劃 + 降低優先級 + 主動監控」可將風險降至最低。RDS 等托管服務通常在內核層面做了深度定制以規避此問題。