MongoDB 副本集 CPU 负载

Question

我正在运行一个相当标准的 MongoDB (3.0.5) 副本集，其中包含 1 个主副本和 2 个副副本。我的 PHP 应用程序的读取首选项是主要的，因此不会在辅助设备上进行读取 - 它们仅用于故障转移。我正在我的应用程序上运行负载测试，它每秒创建大约 600 个查询/更新。这些操作都是针对拥有约 500,000 个文档的集合运行的。但是，查询经过索引优化和支持。任何查询最多不会超过 40 毫秒。

我的问题是所有 3 个节点上的 CPU 负载都非常高 (200% - 300%) - 有时辅助节点上的负载甚至高于主节点上的负载。磁盘 IO 和 RAM 使用似乎没问题 - 至少它们没有达到任何限制。

主服务器的日志文件包含大量 getmore oplog 查询 - 我猜对主服务器的任何操作都会创建一个 oplog 查询。在我看来，这是太多的复制开销，但我之前没有任何在负载下使用 MongoDB 的经验，也没有任何关键数据。

由于设置将不得不在生产中承受更多的负载，我的问题是复制开销是否在预期范围内以及 CPU 负载升高到那么高是否正常，即使在辅助节点上也是如此，或者我是否有什么问题？我不见了？

Answer 1

这样想。无论数据更改操作发生在主服务器上，它也需要发生在每个辅助服务器上。如果有很多这样的操作，并且它们在主节点上产生高 CPU 负载，那么同样的情况将在辅助节点上重复出现。

当然，在您的情况下，您希望主服务器的 CPU 压力更大，因为除了写入之外，它还处理所有读取。可能，在您的场景中，读取相对较少，与写入量相比，读取次数并不多。这可以解释为什么主节点上的负载与辅助节点上的负载大致相同。

my question is whether the replication overhead is to be expected

你所谓的复制开销，我认为是复制的本质。写入压力大的主节点会导致所有次级节点也受到写入压力。

and whether it's normal that the CPU load goes up that high, even on the secondaries

您每秒有 600 个写入查询并且您的 RAM 和磁盘没有压力，对我来说这意味着您已经正确设置了索引。每秒这种写入操作量预计会有高 CPU 负载，因为索引正在被密集使用。

请记住，一旦你收集了更多的数据，索引和内存映射数据可能不再适合内存，然后 RAM 和磁盘都会有压力，而 CPU 不太可能在高加载了。在这种情况下，您可能想要添加更多 RAM 或查看 sharding .