我正在对一个分片的 mongo 集群(5 个分片)执行查询和更新操作，并且遇到了一个相当不寻常的问题(我什至难以清楚地描述)。这是应用程序设置:

• Mongo v3.0.12
• Java 8(独立 JVM)
• 吗非亚 v1.3.2

主分片上的典型后台负载如下所示(使用 mongostat):

insert query update delete getmore command % dirty % used flushes vsize   res qr|qw ar|aw netIn netOut conn set repl     time
     4  3120    785     *0     172   577|0     0.9   80.7       0 72.7G 40.9G   0|1   2|7    2m   163m 3420 rs0  PRI 15:46:29
     4  2324    475     *0     129   417|0     1.3   80.9       0 72.7G 40.9G   0|0   3|2    1m   124m 3420 rs0  PRI 15:46:30
     1  2503    425     *0     121   290|0     1.4   81.0       0 72.7G 40.9G   0|1   1|6    1m   114m 3420 rs0  PRI 15:46:31
     4  2322    469     *0     194   371|0     1.6   81.1       0 72.7G 40.9G   0|2   1|1    1m    86m 3420 rs0  PRI 15:46:32
     4  3349    435     *0     194   443|0     1.8   81.2       0 72.7G 40.9G   0|0   1|1    2m    83m 3420 rs0  PRI 15:46:33
     2  3071    474     *0     159   338|0     2.2   81.6       0 72.7G 40.9G   0|0   1|0    1m    87m 3420 rs0  PRI 15:46:34
     2  2661    394     *0     119   239|0     2.3   81.6       0 72.7G 40.9G   0|0   1|8  925k    81m 3420 rs0  PRI 15:46:35

与主分片的连接:

rs0:PRIMARY> db.serverStatus().connections
{
        "current" : 3388,
        "available" : 47812,
        "totalCreated" : NumberLong(338643)
}

RS0 资源统计:

希望这已经定下了场景。然后我有两个应用程序服务器，它们与同一个数据库但不同的集合交互:

• 应用服务器 A 对集合 1 执行查询和更新
• 应用服务器 B 对集合 2 执行查询和更新

我最近向应用程序服务器 B 添加了一个新的 $set 更新操作，它似乎有一个不幸的副作用，即显着降低应用程序服务器 A 上的更新性能(这样以前花费 < 1="" 秒的操作现在计时为大约="" 60="">

我相信情况就是这样，因为应用服务器 A 的 newrelic CPU 分析在应用服务器 B 上运行设置操作时产生以下结果:

探查器中的同一节点没有在应用程序服务器 B 上运行设置操作:

我注意到，在新的 SET 操作(在应用程序服务器 B 上)期间，mongo 更新操作(在应用程序服务器 A 上)消耗了大约 25% 的总 CPU 时间。虽然 SET 操作未运行，但等效操作仅消耗约 5%。

我最初的假设是我在 mongo 集群上遇到了某种性能瓶颈。我考虑了各种原因:

这是 RS0 的 mongostat 输出，同时 SET 操作在应用程序服务器 B 上运行:

insert query update delete getmore command % dirty % used flushes vsize   res qr|qw ar|aw netIn netOut conn set repl     time
    *0  1405      1     *0      19   132|0     0.0   80.0       0 72.1G 40.9G   0|0   1|0  153k    11m 3419 rs0  PRI 15:46:08
    *0  1340     *0     *0      18   121|0     0.0   80.0       0 72.1G 40.9G   0|0   1|0  144k     7m 3419 rs0  PRI 15:46:09
    *0  1677     *0     *0      27   263|0     0.0   80.1       0 72.1G 40.9G   0|0   1|0  230k     9m 3419 rs0  PRI 15:46:10
    *0  1415      4     *0      35   198|0     0.0   80.0       0 72.1G 40.9G   0|0   1|0  183k     9m 3419 rs0  PRI 15:46:11
    *0  1350     *0     *0      17   123|0     0.0   80.0       0 72.1G 40.9G   0|0   1|0  143k    14m 3419 rs0  PRI 15:46:12
    *0  1036     *0     *0      21   141|0     0.0   80.0       0 72.1G 40.9G   0|0   1|0  130k     9m 3419 rs0  PRI 15:46:13
     1  1099     *0     *0      20   139|0     0.0   80.0       0 72.1G 40.9G   0|0   2|0  132k     8m 3419 rs0  PRI 15:46:14

我注意到负载显着下降。 AWS 系统指标显示了类似的情况，CPU 负载和网络输入/输出下降。

是否是SET操作时进入节点的连接数:

rs0:PRIMARY> db.serverStatus().connections
{
        "current" : 3419,
        "available" : 47781,
        "totalCreated" : NumberLong(338788)
}

是的，连接数量有所增加，但没有达到我认为是问题所在的程度。

然后我考虑到 SET 操作可能会很慢，所以我启用了 2 秒的 slowMS 阈值的数据库分析。在 SET 操作期间，慢速查询日志仅获得一个条目(这是由于应用程序服务器 A 上已知的慢速操作)，因此也无济于事。

然后我使用 iostat 查看了配置为使用实例 SSD 存储的日志卷的性能:

iostat -x 5 -t

这同样显示了与 mongostat 类似的画面，即当我看到应用程序服务器 A 上的更新速度变慢/阻塞时，负载似乎减少了，而 SET 操作正在运行，而应用程序服务器 B 上正在运行。

不幸的是，这就是我用尽了想法和调试想法的地方。如果能进一步帮助解决此问题，我将不胜感激。

最佳答案

看起来这个问题的原因是:

• 如果副本开始滞后，使用 majority write concern 会阻止任何其他数据库操作进入同一个 mongo 集群。
• 延迟的原因是我们使用了 $push，它在特定分片的 oplog 中创建了热点，请参阅 https://jira.mongodb.org/browse/SERVER-9784了解更多信息。

关于java - 意外的 mongodb 更新被阻止，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44398893/