node.js - Mongo 遭受大量故障

Question

我在我的 mongostat 输出中看到了一个巨大的(~200++)故障/秒数，尽管锁定百分比非常低:

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

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

显然，我没有足够的内存来满足所有 cahin mongo 想要做的事情(顺便说一句，由于磁盘 IO，这会导致 CPU 使用率很高)。

我找到了 this document这表明在我的场景中(高故障，低锁定百分比)，我需要“横向扩展读取”和“更多磁盘 IOPS”。

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

db.setProfilingLevel(1);

但是，这对我没有多大帮助，因为输出的统计信息只是显示我的查询速度很慢，但我很难将这些信息转换为导致页面错误的查询...

如您所见，这导致我的 PRIMARY mongo 服务器上的 CPU 等待时间很长(几乎 100%)，尽管 2x SECONDARY 服务器不受影响...

以下是 Mongo 文档对页面错误的评价:

Page faults represent the number of times that MongoDB requires data not located in physical memory, and must read from virtual memory. To check for page faults, see the extra_info.page_faults value in the serverStatus command. This data is only available on Linux systems.

Alone, page faults are minor and complete quickly; however, in aggregate, large numbers of page fault typically indicate that MongoDB is reading too much data from disk and can indicate a number of underlying causes and recommendations. In many situations, MongoDB’s read locks will “yield” after a page fault to allow other processes to read and avoid blocking while waiting for the next page to read into memory. This approach improves concurrency, and in high volume systems this also improves overall throughput.

If possible, increasing the amount of RAM accessible to MongoDB may help reduce the number of page faults. If this is not possible, you may want to consider deploying a shard cluster and/or adding one or more shards to your deployment to distribute load among mongod instances.

所以，我尝试了推荐的命令，这非常无用:

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+Advice+and+FAQ#IndexingAdviceandFAQ-MakesureyourindexescanfitinRAM .

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

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