意外的mongodb更新被阻止

我对分片的mongo集群（5个分片）执行查询和更新操作，并且遇到了一个相当不寻常的问题（我甚至很难清楚地描述）。这是应用程序设置：意外的mongodb更新被阻止

蒙戈v3.0.12
爪哇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资源统计：

希望这拉开了序幕。然后我有以相同的数据库，但不同的集合互动两个应用程序服务器：

应用服务器进行查询和更新，以收集1个
应用服务器B进行查询和更新集合2

我最近向应用程序服务器B添加了一个新的$集更新操作，并且它似乎具有显着降低应用程序服务器A上的更新性能的不幸副作用（例如，先前需要1秒钟的操作的操作现在正在〜 60秒）。

相信是这种情况作为NewRelic的CPU性能分析，应用服务器A的，正在产生以下结果的设定操作是在应用服务器B运行时：

而且在同一个节点在探查不会对应用服务器B上运行的设置操作：

我从这些注意到，新的设置操作期间（在申请服务器B）mongo更新操作（在应用程序服务器A上）占CPU总时间的25％。虽然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负载下降&网络IN/OUT。

它是连接的设置操作期间数到节点：

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

是的，有增加的连接数而不是一个点，我认为这是个问题。

然后我考虑了也许SET操作可能会很慢，所以我使用slowMS阈值为2秒来启用db分析。在SET操作期间，慢速查询日志仅获得一个条目（这是由于应用程序服务器A上已知的缓慢操作），所以也没有帮助。

我然后看到日志卷，其被配置为使用例如SSD存储器的性能，采用的iostat：

iostat -x 5 -t

这同样示出了类似的图片作为mongostat，即负载出现时降低我看到应用程序服务器A上的减速/阻塞更新，而SET操作正在运行，正在应用程序服务器B上运行。

不幸的是，我用完了想法和调试思路。我非常感谢解决此问题的进一步帮助。

来源

2017-06-06 MarcF

进一步的调查将考虑复制滞后（我使用MAJORITY写关注）。 – MarcF

看来，这个问题的原因是：

使用多数写的关注会阻止任何其他数据库操作去同蒙戈集群如果副本开始落后。
滞后的原因是我们使用$ push，它在oplog中为特定的碎片创建了热点，请参阅https://jira.mongodb.org/browse/SERVER-9784以获取更多信息。

来源

2017-06-09 09:24:46 MarcF

意外的mongodb更新被阻止

回答

相关问题