☰

MongoDB 被 OOM 殺死

tag-icon • tag-icon mongodb oom-killer
MongoDB 被 OOM 殺死

我們在三台機器上運行 mongodb 複製集。所有三台機器都有大約 16GB，但只有 255MB Swap。 Swappiness 保留預設值 60。資料庫比 16GB 大得多，但這對我們來說沒關係。真正的工作集要小得多。

我們面臨的問題是主消耗耗盡了所有可用內存，然後被 OOM-Killed。我知道mongodb就是這樣管理記憶體的。

伺服器被 OOM 殺死後，必須有人手動重新啟動它。

有辦法可以防止 mongodb 被 OOM 殺死嗎？調整交換性？增加交換空間？我認為這些設定只會增加 mongod 被殺死之前的寬限期。

答案1

OOM殺手不是辦法任何人管理記憶體；這是 Linux 核心處理致命故障的方法，以避免系統鎖定的最後希望！

你該做的是：

  • 確保你有足夠的交換空間。如果你確定，還可以再增加。

  • 實施資源限制！至少對於您希望使用內存的應用程式來說（如果您不希望它們使用內存，則更是如此 - 這些應用程式通常最終會出現問題）。請參閱 shell 中的 ulimit -v（或限制位址空間）命令，並將其放在應用程式啟動之前的 init 腳本中。您還應該限制其他內容（例如進程數-u 等）...這樣，當沒有足夠的內存時，應用程式將收到ENOMEM 錯誤，而不是內核給它們不存在的內存，然後瘋狂地殺死周圍的一切！

  • 告訴內核不要過度使用記憶體。你可以這樣做：

    迴聲“0”> / proc / sys / vm / overcommit_memory

    甚至更好（取決於您的交換空間量）

    迴聲“2”> / proc / sys / vm / overcommit_memory;迴聲“80”> / proc / sys / vm / overcommit_ratio

    看關閉過度使用了解更多。

    這將指示核心在為應用程式提供它實際上沒有的記憶體時要更加小心（與世界全球經濟危機的相似之處是驚人的）

  • 作為最後的手段，如果你的系統上除了 MangoDB 之外的所有東西都是消耗性的（但請先修復上面的兩點！）你可以降低它被殺死的機會（或甚至確保它不會被殺死 - 即使替代方案是掛起機器而沒有任何工作）通過調整 /proc/$pid/oom_score_adj 和/或 /proc/$pid/oom_score。

    echo "-1000" > /proc/`pidof mangod`/oom_score_adj

    看馴服 OOM 殺手有關該主題的更多資訊。

相關內容