MySQL OOM 系列一：Linux 記憶體分配策略與 Overcommit 機制

引言：一次真實的 RDS OOM 故障

線上 4GB RDS 實例發生 OOM，MySQL 進程被直接殺掉。要理解此問題，必須從 Linux 記憶體分配策略講起。

Linux 獨特的記憶體分配哲學

傳統認知（Solaris 等）：malloc 失敗返回 NULL 表示無可用記憶體。
Linux 實際：採用 Overcommit（過量分配） 策略——假設應用申請記憶體後不會立即使用，允許申請超過「物理記憶體 + Swap」總和的虛擬地址空間。實際使用時，OS 通過換出、回收頁面來滿足需求。

Overcommit 三種模式（/proc/sys/vm/overcommit_memory）

實驗驗證

兩個測試程式：

// 僅 malloc 不使用
while(1) { myblock = malloc(1MB); if(!myblock) break; printf("Allocated %d MB\n", ++count); }

// malloc 後立即 memset 填充
while(1) { myblock = malloc(1MB); if(!myblock) break; memset(myblock,1,1MB); printf("Allocated %d MB\n", ++count); }

環境：1GB RAM + 400MB Swap 虛擬機

結果：

• 僅 malloc：成功申請遠超物理記憶體的空間（虛擬記憶體 VIRT 激增，實際 RES 不變）
• malloc + memset：申請到 ~1.4GB 時失敗（受限於物理+Swap）

風險與應對：OOM Killer 機制

Overcommit 基於「不會大量程式同時用滿資源」假設，有風險。Linux 引入 OOM Killer：當可用記憶體（含 Swap）即將耗盡時，選擇性殺掉進程釋放記憶體。

下一章將詳細剖析 OOM Killer 如何選擇犧牲者。