我正在运行一个相当标准的MongoDB（3.0.5）副本集，其中包含1个主副本和2个副主席。我的PHP应用程序的读取首选项是主要的，因此不会在辅助节点上进行读取 - 它们仅用于故障转移。我正在对我的应用程序运行负载测试，每秒创建大约600个查询/更新。这些操作都是针对具有~500,000个文档的集合运行的。但是，索引会优化并支持查询。任何查询都不会超过40毫秒。
我的问题是我在所有3个节点（200％ - 300％）上获得了相当高的CPU负载 - 有时候辅助节点上的负载甚至高于主节点上的负载。磁盘IO和RAM使用似乎没问题 - 至少它们没有达到任何限制。
主要的日志文件包含大量的getmore oplog查询 - 我猜想主要的任何操作都会创建一个oplog查询。在我看来，这是太多的复制开销，但我没有任何关于负载的MongoDB的经验，我没有任何关键数字。
由于设置必须承受更多的生产负载，我的问题是是否预期复制开销以及CPU负载是否正常上升，即使在辅助设备上也是正常的我不见了？
答案 0 :(得分：1)
以这种方式思考。无论主数据库发生什么数据更改操作，它都需要在每个次要数据上发生。如果有很多这样的操作并且它们在主服务器上创建了高CPU负载，那么同样的情况将在辅助服务器上重复出现。
当然，在你的情况下，你会期望主要的CPU更加紧张，因为除了写入之外，它还处理所有的读取。可能在您的场景中，读取相对较轻，与写入量相比，读取次数较少。这可以解释为什么主要负载与次要负载大致相同。
我的问题是是否需要复制开销
你所谓的复制开销我认为是复制的本质。写作强调的主要原因是所有辅助语言都会受到写入的压力。
以及CPU负载是否正常上升，即使是在辅助设备上也是如此
您每秒有600次写入查询，并且您的RAM和磁盘没有压力，对我而言，这表示您已正确设置索引。由于索引被大量使用，因此每秒的写入操作量预计会产生高CPU负载。
请记住，一旦收集到更多数据，索引和内存映射数据可能不再适合内存，然后RAM和磁盘都会受到压力，而CPU不太可能低于再加载。在这种情况下，您可能希望添加更多RAM或查看sharding。