Mongo有很多缺点

Question

我在mongostat的输出中看到了巨大的每秒（约200次）故障数，尽管锁率非常低：

我的Mongo服务器运行在Amazon云上的m1.large实例上，因此它们每个都有7.5GB的RAM::

root:~# free -tm
             total       used       free     shared    buffers     cached
Mem:          7700       7654         45          0          0       6848

显然，我没有足够的内存来满足cahing mongo想要做的所有事情（顺便说一句，由于磁盘IO，这会导致巨大的CPU使用率%）。

我发现这篇文档表明，在我的场景中（高故障、低锁定%），我需要“扩展读取”和“更多磁盘IOPS”

我正在寻找如何最好地实现这一点的建议。也就是说，我的节点执行了许多不同的潜在查询。js应用程序，我不确定瓶颈发生在哪里。当然，我试过了

db.setProfilingLevel(1);

然而，这对我并没有多大帮助，因为输出的统计数据只显示了缓慢的查询，但我很难将导致页面错误的查询信息转换为这些信息。。。

如您所见，这导致我的主mongo服务器上的CPU等待时间非常长（接近100%），尽管2x辅助服务器不受影响。。。

以下是Mongo文档对页面错误的看法：

页面错误表示MongoDB需要不在物理内存中的数据，并且必须从虚拟内存读取数据的次数。要检查页面错误，请参阅附加信息。page_serverStatus命令中的错误值。此数据仅在Linux系统上可用。

单独而言，页面错误很小且很快完成；然而，总的来说，大量页面错误通常表明MongoDB从磁盘读取了太多数据，并且可以表明许多潜在的原因和建议。在许多情况下，MongoDB的读取锁会在页面错误后“屈服”，以允许其他进程读取并避免阻塞，同时等待下一页读取到内存中。这种方法提高了并发性，在大容量系统中，这也提高了整体吞吐量。

如果可能，增加MongoDB可访问的RAM量可能有助于减少页面错误的数量。如果这不可能，您可能需要考虑部署一个分片集群和/或在部署中添加一个或多个分片以在mon神实例之间分配负载。

因此，我尝试了建议的命令，但效果非常糟糕：

PRIMARY> db.serverStatus().extra_info
{
    "note" : "fields vary by platform",
    "heap_usage_bytes" : 36265008,
    "page_faults" : 4536924
}

当然，我可以增加服务器大小（更多RAM），但这很昂贵，而且似乎矫枉过正。我应该实现分片，但我实际上不确定哪些集合需要分片！因此，我需要一种方法来隔离故障发生的位置（哪些特定命令导致故障）。

谢谢你的帮助。

Answer 1

我们真的不知道你的数据/索引是什么样子的。

不过，MongoDB优化的一条重要规则是：
确保索引适合RAM。http://www.mongodb.org/display/DOCS/Indexing建议和常见问题#索引建议和常见问题确保您的索引扫描到AM。

考虑到您的文档越小，您的密钥/文档比率就越高，您的RAM/磁盘大小比率就需要越高。

如果您可以稍微调整一下模式，将一些数据集中在一起，并减少所需的键数，这可能会有所帮助。