您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 資料庫相關知識

MySQL 從庫觸發 OOM Killer 根因分析與解決方案

編輯：MySQL 資料庫相關知識

問題現象

生產環境頻繁收到 MySQL 實例記憶體不足告警，登入服務器發現 MySQL 佔用 99% 記憶體。若未及時處理，Linux 內核會自動觸發 OOM Killer 終止 mysqld 進程，dmesg 記錄顯示：

Mar 9 11:29:16 xxxxxx kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Mar 9 11:29:16 xxxxxx kernel: Pid: 99275, comm: mysqld Not tainted 2.6.32-431.el6.x86_64 #1

環境基線

OS：CentOS 6.5 (Final)，Kernel 2.6.32-431.el6.x86_64（物理機）
MySQL：Percona 5.6.23-72.1-log（單實例）
觸發場景：從庫無論是否有其他連接，記憶體週期性暴漲觸發 OOM Killer

排查過程

1. 記憶體配置檢查

InnoDB Buffer Pool 佔物理記憶體約 60%，排除配置過大問題。

2. 系統參數檢查

vm.swappiness=1、overcommit_memory 等參數正常。雖可臨時設置 oom_score_adj=-17 防止被殺，但無法根治且有風險。

3. MySQL 內部排查

嘗試 FLUSH TABLES 觀察內存變化，未發現明顯釋放。檢查 innodb_buffer_pool_instances 與 innodb_buffer_pool_size 搭配是否導致超售（參考 Bug #79850），但配置合理。排除從庫過濾規則導致 OOM（無設置過濾）。

4. 關鍵突破：Stop/Start Slave 釋放記憶體

執行 STOP SLAVE; START SLAVE; 後卡頓約 3 分鐘，記憶體瞬間釋放 20GB+。確認問題源於從庫複製線程。

監控數據佐證

02:40:01 PM 553252 131492784 99.58 83216 615068 132406792 89.20
03:00:01 PM 39302700 92743336 70.24 95908 925860 132413308 89.21
03:10:01 PM 38906360 93139676 70.54 109264 1292908 132407836 89.21
03:20:01 PM 38639536 93406500 70.74 120676 1528272 132413136 89.21

03:00 左右記憶體佔用從 99% 驟降至 70%，對應執行重啟 Slave 時刻。