内存安全的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任务

回答

相关问题