MySQL innodb_buffer_pool_size 內存分配機制：虛擬內存 vs 物理內存與 OOM Killer 風險

MySQL innodb_buffer_pool_size：虛擬內存分配、物理映射與 OOM Killer

常見誤區：設定 innodb_buffer_pool_size=8G，以為啟動瞬間佔用 8G 物理內存。實際上 MySQL 啟動時僅在虛擬地址空間預留範圍，首次寫入頁時才通過缺頁中斷映射到物理內存。

Linux malloc 機制

• malloc / mmap 分配虛擬地址空間，返回指針。
• 實際訪問該地址時觸發缺頁中斷，內核分配物理頁並建立映射。
• 因此 top 顯示的 VIRT 會很大，RES 隨實際使用緩慢增長。

風險場景：過度承諾

-- 物理 16G + Swap 8G
-- 程序 A 已 malloc 22G（未實際用）
-- MySQL 啟動 innodb_buffer_pool_size=8G（虛擬分配成功）
-- A 開始大量寫入，物理+Swap 僅剩 2G
-- MySQL 也開始寫入，Swap 耗盡 -> OOM Killer 啟動
-- OOM 選擇佔用物理內存最多的進程殺掉（通常是 MySQL）

OOM Killer 判斷依據

• /proc//oom_score：分數越高越易被殺。
• 佔用物理頁最多的進程優先被殺。
• 可通過 echo -1000 > /proc//oom_score_adj 保護關鍵進程（不推薦常規使用）。

最佳實踐

1. Buffer Pool 設為物理內存 60-75%，預留 OS cache、其他進程、Swap 空間。
2. 關閉 Swap 或設極小（如 1-2G），避免 Swap 抖動；若必須開 Swap，設置 vm.swappiness=1。
3. 監控 RES 而非 VIRT：pmap -x 或 cat /proc//smaps 看實際物理佔用。
4. 啟用大頁：innodb_large_prefix=ON + OS 配置 HugePages，減少頁表開銷、鎖定內存防 Swap。
5. 容器環境：設置 memory.limit_in_bytes 略大於 Buffer Pool，避免容器 OOM 殺掉 MySQL。

總結

innodb_buffer_pool_size 是虛擬地址空間預留，物理內存按需分配。生產環境務必按物理內存紅線規劃，留足餘量給 OS 與其他進程，防止 OOM Killer 誤殺 MySQL 導致不可用。