Linux OOM 排查實務：如何解決 Apache 記憶體耗盡導致的 WordPress 當機？

本文目錄

1. 01一、 現場鑑識：確認「真的」是 OOM
2. 01.11. 檢查核心日誌 (Kernel Log)
3. 01.22. 觀察當前記憶體壓力
4. 02二、 鎖定嫌疑犯：誰吃光了記憶體？
5. 03三、 架構分析：為什麼多半是 MPM Prefork 出事？
6. 04四、 容量規劃：如何計算「合理」的 Apache 配置？
7. 04.1步驟 1：測出平均記憶體消耗
8. 04.2步驟 2：計算 MPM Prefork 的 MaxRequestWorkers
9. 04.3步驟 3：計算 MPM Event 的配置
10. 05五、 處置建議與總結

當 Linux 主機發生 OOM (Out Of Memory) 時，最常見的症狀是整機回應延遲、Swap 分區瞬間飽和，緊接著某些關鍵服務（例如 Apache httpd 或 MySQL）被系統強制終止。 許多工程師在第一時間會誤判為 DDoS 攻擊，但實際上，這往往是伺服器資源配置不當所致。本文將整理一套標準的實務排查流程（SOP），並以 Apache 為例，深入探討如何進行合理的容量規劃 (Capacity Planning)。

一、 現場鑑識：確認「真的」是 OOM

在懷疑記憶體不足之前，我們必須先從系統日誌中尋找確鑿的證據。

1. 檢查核心日誌 (Kernel Log)

使用以下指令搜尋系統日誌，尋找核心殺手 (Kernel Killer) 的蹤跡：

# 檢查系統訊息
grep -i "Out of memory" /var/log/messages
# 或者使用 dmesg
dmesg | grep -i "killed process"

如果您看到類似下方的輸出，則確認是 OOM 無誤：

Out of memory: Kill process 2345 (httpd) score 950 or sacrifice child
Killed process 2345 (httpd) total-vm:40860kB, anon-rss:2048kB, file-rss:0kB

這代表 Linux 核心為了保護系統不當機，啟動了 OOM Killer，並選擇殺死分數 (Score) 最高、佔用最多記憶體的 httpd 進程。

2. 觀察當前記憶體壓力

使用 free -m 或 vmstat 1 5 觀察。如果發現 Swap used 居高不下，且 CPU 長時間處於 wa (I/O Wait) 狀態，這表示系統正在瘋狂地進行記憶體置換 (Swapping)，這是崩潰的前兆。

二、 鎖定嫌疑犯：誰吃光了記憶體？

確認是記憶體問題後，下一步是找出「大胃王」。使用 top 或 ps 進行排序：

ps aux --sort=-%mem | head -n 10

在 WordPress 環境中，通常會發現前幾名都是 httpd (Apache) 或 php-fpm。我們需要進一步分析單一進程的「真實」記憶體佔用：

• VmRSS (Resident Set Size)： 該進程實際佔用的物理記憶體。
• 判斷準則：
  • 如果單個進程的 VmRSS 異常巨大，可能是程式碼有 Memory Leak。
  • 如果單個進程 VmRSS 正常（例如 80MB），但進程數量極多，則屬於「併發參數配置不當」。

三、 架構分析：為什麼多半是 MPM Prefork 出事？

Apache 的運作模式 (MPM) 決定了記憶體的消耗方式。實務上，90% 的 OOM 案例都發生在 Prefork 模式。

四、 容量規劃：如何計算「合理」的 Apache 配置？

無論使用哪種 MPM，核心邏輯都是數學問題：「你的車庫（記憶體）能停幾輛車（Process）？」

步驟 1：測出平均記憶體消耗

我們可以使用一段腳本，精準計算出當前環境下，平均每個 Apache 子進程佔用的記憶體大小：

ps -ylC httpd | awk '
  { x += $8; y += 1 }
  END {
    print "Apache Memory Usage (MB): " x/1024;
    print "Average Process Size (MB): " x/((y-1)*1024)
  }'

假設輸出結果為：平均每個 Process 約 100MB。

步驟 2：計算 MPM Prefork 的 MaxRequestWorkers

這是最關鍵的一步。許多設定檔預設值為 150 或 256，但對於小記憶體主機來說，這是災難性的設定。 範例試算：

• 主機實體記憶體：16 GB
• 預留給 OS / DB / 其他服務：4 GB
• 可用給 Apache 的記憶體：12 GB

12,000 MB ÷ 100 MB = 120 結論： 您的 MaxRequestWorkers 理論上限是 120。為了保留緩衝區（避免流量突增），建議設定在 100 左右。如果設定成 400，OOM 只是時間問題。

步驟 3：計算 MPM Event 的配置

Event 模式的計算稍微複雜一點，但邏輯相同。假設平均每個子進程約 10MB（Event 模式下較小），可用記憶體 7GB： 7,000 MB ÷ 10 MB = 700（最大並發線程數） 在 Event 模式下，我們需要配置 ServerLimit (進程數) 與 ThreadsPerChild (每進程線程數)。 建議配置範例 (目標 600 並發)：

• ServerLimit 24
• ThreadsPerChild 25
• MaxRequestWorkers 600 (24 * 25)

五、 處置建議與總結

當您確認 OOM 發生後，請依循以下步驟處理：

1. 緊急止血： 透過 systemctl restart httpd 釋放記憶體。若無效，暫時調整防火牆限制連線。
2. 參數調校： 依據上述公式，修改 /etc/httpd/conf.modules.d/ 或 apache2.conf 中的 MaxRequestWorkers 數值。不要盲目調大，要「調準」。
3. 壓力測試： 設定完成後，建議使用 httperf 或類似工具進行壓測，觀察錯誤率與回應時間，驗證設定是否穩定。
4. 架構升級 (最終解法)： 如果調校後記憶體依然不足，建議升級主機規格，或是參考我們的另一篇案例，導入負載平衡 (Load Balancing) 架構。

還是搞不定伺服器的不穩定問題？ 複雜的 Linux 底層優化與參數調校，交給專業的技術團隊來處理。 預約 WordPress 效能診斷服務 →