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 的压力更大，因为除了写入之外，它还处理所有读取。可能在您的场景中，读取相对较少，与写入量相比，读取量并不多。这可以解释为什么主节点上的负载与辅助节点上的负载大致相同。

我的问题是复制开销是否可以预期

你所说的复制开销我认为是复制的本质。主节点被写入强调会导致所有次节点也被写入强调。

CPU 负载上升这么高是否正常，即使在辅助节点上也是如此

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

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