蒙戈遭受了大量的错误
我在mongostat输出中看到了一个巨大的（〜200 ++）故障/秒数，尽pipe非常低的locking百分比：
我的Mongo服务器在亚马逊云上的m1.large实例上运行，所以它们每个都有7.5GB的RAM ::
root:~# free -tm total used free shared buffers cached Mem: 7700 7654 45 0 0 6848 显然，我没有足够的内存来满足所有的caong mongo想要做的事情（这是由于磁盘IO导致CPU占用率很高）。
我发现这个文件表明，在我的情况下（高故障，低locking％），我需要“扩展读取”和“更多磁盘IOPS”。
我正在寻找如何最好地实现这一目标的build议。 也就是说，我的node.js应用程序执行不同潜在查询的LOTS，我不知道瓶颈在哪里发生。 当然，我已经尝试过了
db.setProfilingLevel(1);
然而，这并没有太大的帮助，因为输出的统计数据显示我的查询速度很慢，但是我很难将那些查询导致页面错误的信息翻译出来。
正如你所看到的，虽然2 SECONDARY服务器不受影响，但是这会导致我的PRIMARY mongo服务器上的CPU等待时间过长（接近100％）…
以下是Mongo文档关于页面错误的说明：
页面错误表示MongoDB要求数据不在物理内存中的次数，并且必须从虚拟内存读取。 要检查页面错误，请参阅serverStatus命令中的extra_info.page_faults值。 此数据仅在Linux系统上可用。
单独页面错误很小，很快就完成了。 然而，总的来说，大量的页面错误通常表明，MongoDB正在从磁盘读取太多的数据，可以指出一些潜在的原因和build议。 在许多情况下，MongoDB的读取locking会在页面错误后“屈服”，以允许其他进程在等待下一页读入内存时读取并避免阻塞。 这种方法提高了并发性，在大批量系统中，这也提高了整体吞吐量。
如果可能的话，增加MongoDB访问RAM的数量可能有助于减less页面错误的数量。 如果这不可行，您可能需要考虑部署分片群集和/或向您的部署添加一个或多个分片以在mongod实例之间分配负载。
所以，我尝试了这个非常无用的推荐命令：
PRIMARY> db.serverStatus().extra_info { "note" : "fields vary by platform", "heap_usage_bytes" : 36265008, "page_faults" : 4536924 }
当然，我可以增加服务器的大小（更多的内存），但这是昂贵的，似乎是矫枉过正。 我应该实现分片，但我实际上不确定哪些集合需要分片。 因此，我需要一种方法来隔离故障发生的位置（具体的命令是什么引起故障）。
谢谢您的帮助。
我们并不知道你的数据/索引是什么样的。
不过，MongoDB优化的一个重要规则是：
确保你的索引适合RAM。 http://www.mongodb.org/display/DOCS/Indexing+Advice+and+FAQ#IndexingAdviceandFAQ-MakesureyourindexescanfitinRAM 。
考虑到你的文件越小，你的密钥/文件比率越高，你的RAM / Disksize比率就越高。
如果你可以调整你的模式来把一些数据集中在一起，并减less你需要的键的数量，这可能会有所帮助。