我的机器有42GB内存，总索引大小为40GB（工作集应该100％填充，因为索引都在UUID列上）。 我怀疑我的工作集太大，页面错误开始增加巨大，例如从平均20跳到120。
我发现似乎mongod没有使用我所有的记忆，例如
ps ax | grep mongod 23051 mongod 20 0 338g 7.7g 7.5g S 87.8 16.4 1533:17 /usr/bin/mongod -f /etc/mongod.conf 目前仅使用7.7G。
而使用2.4的工作集估算器，我发现50多个工作集只有大约650MB，似乎是从我的数据大小意外。
"workingSet" : { "note" : "thisIsAnEstimate", "pagesInMemory" : 166069, "computationTimeMicros" : 49281, "overSeconds" : 50 },
你有什么主意吗？
首先，我build议你看看这里：
https://jira.mongodb.org/browse/SERVER-9415
这个问题讨论了很多相同的话题。 总结一下：由于MongoDB中的日志工作方式以及它如何重新映射内存，可能会导致mongod进程的驻留内存看起来很低。 如果你看看free命令的输出，并且你的文件系统caching比较满，那么你更有可能会碰到这个驻留内存exception报告（假设mongod是系统上唯一真正沉重的内存消耗者，课程）。
但是，MongoDB（至less在Linux上）只报告硬（实际）页面错误，而不是报告进程请求页面已经在内存中，但不是请求进程“拥有”时发生的软页面错误。 因此，您应该关心页面错误的增加，因此build议您的数据目前不适合内存，因此您必须打开磁盘才是最好的衡量标准之一。
在确认你想要的内容都在内存中，你可以使用touch命令将你想要的索引和数据加载到文件系统caching（不驻留）中。 应该注意的是，这是一个有点直截了当的工具，因为它只是将整个数据集和/或整个索引加载到caching中，并且可能会导致系统加载/locking – 谨慎使用。 根据您的数据集，可以更高效地使用查找查询和解释来加载最近或已知的热门数据。 像这样的东西：
db.collection.find({criteria for loading data}).explain()
或者，为了确保加载了特定的索引，请添加明确的提示：
db.collection.find({criteria for loading data}).hint({index name})explain()
还有一点需要注意的是当你打到磁盘时，将数据加载到内存的效率。 一般来说，这是IO和内存利用率之间的折衷，但是如果您的首要任务是内存效率，并且您有一些闲置的IO来解决问题，那么在MongoDB上，您通常需要使用blockdev来调整您的预读设置命令。 有关更多信息，请参阅此处和此处的其他Serverfault问题/答案。