內存安全的mongodb任務

在爲50GB集合的時間戳字段添加單個索引時，MongoDB在96GB根服務器上的內存不足。內存安全的mongodb任務

MongoDB是否有任何選項在「安全模式」下運行查詢或任務，例如：不會太多地減少內存？它看起來非常敏感，可能會崩潰，例如通過在非索引時間戳字段上使用$ lte/$ gt運行一些查詢查詢。

2013-02-05 ledy

您使用的是Linux嗎？ – Adil

是的，2.6.32-5-amd64，debian。 – ledy

這是好的還是與mongo「不兼容」？ dmesg | grep -i numa [0.000000] NUMA：從40000分配的memnodemap - 58840 [0.000000] NUMA：使用20作爲散列轉換。 – ledy

我無法控制它，但不應該有一個MongoDB的配置設置爲「安全」，這會確保釋放內存一旦突破極限？也許甚至在它阻止其他進程之前，或者被殺手殺死？

MongoDB不使用自己的內存管理。相反，它使用操作系統的LRU。操作系統是分頁文件如此之大，因爲它已經使用了分配給mongod的內存量，也就是說你的工作集大於爲MongoDB提供的備用內存量，因爲這樣的MongoDB會爲大多數頁面交換頁面錯誤，而不是所有的頁面錯誤數據（尋呼的一個很好的參考：http://en.wikipedia.org/wiki/Paging）。

我會強烈建議不要在這種情況下，限制MongoDB的，因爲它會運行更糟糕然而，特別是在Linux上，你實際上可以在mongo用戶使用ulimit您正在使用運行mongod：http://docs.mongodb.org/manual/administration/ulimit/

不MongoDB可以選擇以「安全模式」運行查詢或任務，例如不會太多地減少內存？

不是。

它看起來非常敏感並且可能會墜毀，例如，通過在非索引時間戳字段上使用$ lte/$ gt運行一些查詢查詢。

當然，這應該不會引起MongoDB中的OOM異常，它可能表明內存泄漏的地方：http://docs.mongodb.org/manual/administration/ulimit/

如果限制運行的MongoDB的系統上的常駐內存的大小，你的風險，允許操作系統在正常情況下終止mongod進程。不要設置這個值。如果操作系統（即Linux）通過OOM殺手殺死你的mongod，檢查serverStatus的輸出並確保MongoDB沒有泄漏內存。

來源

2013-02-05 21:13:26 Sammaye

我不能相信我的RAM更少。我使用的唯一的集合是50GB，總RAM是少於96GB。它在散列字段上只有一個索引。當然，值得嘗試一下時間戳上的索引以獲得「排序」。但是這不應該成爲目前和不穩定的原因，因爲當一些查詢完成後，它會被殺手殺死。除了.find之外，每秒還有大約20個刀片。在我看來，這並不是很多，特別是當幾乎沒有任何指數時。 – ledy

@ledy不是不是這裏可能還有另一個問題，我想你可能會得到一個內存泄漏，我添加了一個關於它的編輯 – Sammaye

ulimit應該沒問題：ulimit -a http://nopaste.info/340ff18546。 html和serverStatus沒有警告：MEM \t { 「位」：NumberInt（64），「駐留」：NumberInt（35877），「虛擬」：NumberInt（393373），「支持」：真，「映射「：NumberInt（196545），」mappedWithJournal「：NumberInt（393090） } – ledy

它似乎非常敏感，可以崩潰，例如，通過在非索引時間戳字段上使用$ lte/$ gt運行一些查詢查詢。

這是殺死它的OOM殺手，因爲你的mongod實例正在將很多頁面交換到RAM中。你可能有很多進程競爭RAM。您可以指示的Linux如下地不敢殺的mongod守護進程：

sudo echo -17 > /proc/<process if of mongod>/oom_adj

你無法控制內存的MongoDB使用了多少，很遺憾。我建議看看background indexing docs on mongodb。而一些更爲有用的鏈接：

來源

2013-02-05 20:52:55 Adil

我無法控制它，但不應該有一個「安全」的mongodb配置設置，它確保一旦它突破極限就釋放RAM？也許甚至在它阻止其他進程之前，或者被殺手殺死？ – ledy

沒有一個，mongodb依靠操作系統的虛擬內存管理器來交換數據文件。我已經更新了相關鏈接的答案。 – Adil

內存安全的mongodb任務

回答

相關問題