MongoDB副本集CPU负载

Question

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

我的问题是，我在所有3个节点（200％-300％）上获得了相当高的CPU负载 - 有时副本上的负载甚至高于主节点上的负载。磁盘IO和内存使用似乎没问题 - 至少它们没有达到任何限制。

主日志文件包含大量的getmore oplog查询 - 我猜测主节点上的任何操作都会创建oplog查询。在我看来，这是太多的复制开销，但我在加载MongoDB之前没有任何经验，并且我没有任何关键数字。

由于安装程序将不得不容忍更多的生产负载，我的问题是是否需要复制开销，以及CPU负载是否正常上升，即使是在次级系统上，或者是否存在某些问题错过了？

Answer 1

想想这样。无论数据更改操作发生在小学，它也需要发生在每个辅助中。如果有很多这样的操作，并且它们对主服务器造成高CPU负载，那么同样的情况会在次服务器上重演。

当然，在你的情况下，你会希望主CPU的压力更大，因为除了写操作外，它还处理所有的读操作。在您的情况中，读取可能相对较轻，并且与写入数量相比，其数量并不多。这可以解释为什么主要负载与辅助负载大致相同。

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

你叫什么复制开销我看到作为复制的性质。由写入强调的主要结果在所有的次级写入中也被强调。

以及是否是正常的，CPU的负荷上升高，甚至在二级

你有每秒600次写的查询和你的内存和硬盘都没有强调，对我来说这意味着你已经正确设置了索引。由于这些索引正在被大量使用，因此预计每秒写入操作量会导致较高的CPU负载。

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