关于mongodb:记一次mongo周期性慢查询问题的定位

78次阅读

共计 1234 个字符,预计需要花费 4 分钟才能阅读完成。

问题

线上 mongodb 主库经常出现以 5 分钟为周期性的慢查问。在排除业务代码 bug,机器 cpu/io/memory 资源限度后。最终发现是 mongodb 的 bug,因为这是一个十分典型的加锁导致的性能不佳问题。故做一下记录。

过程

局部业务呈现超时报错

局部业务呈现超时报错后,开始定位:

  • 这个超时报错是周期性的,距离是 5 分钟。
  • mongodb 链接数量呈周期性回升。
  • 局部申请的 rtt 在同一个工夫点显著回升。
  • 所有高 rtt 慢查问都呈现在主库,并且集中在一秒内。

排除了业务出错的可能性

排除业务问题的起因如下:

  • 所有的申请都会呈现慢查问,而这些查问在平时应该在 0.5MS 左右返回,比方主键齐全命中,collection 规模很小,且返回 doc 不大。
  • 在呈现慢查问前后,mongodb 业务无变动。

因没有秒级监控数据,未在机器层面发现其它异样

  • cpu 的使用率,上下文切换,中断都无异样。
  • disk/network io 无异样。max 磁盘使用率在 %20 以下,等待时间和队列都很低。
  • 内存异样变动。

减少了专门的告警,抓到秒级的 mongotop 日志


                                     ns       total        read      write    20XX-XX-XXTXX:XX:06+08:00
            XXXXXXXXXXX    432784ms    427448ms     5336ms                             
              XXXXXXXXXXX.XXXXXXXXXXX    156077ms    156077ms        0ms                             
        XXXXXXXXXXX.XXXXXXXXXXX    123833ms     92224ms    31608ms                             
  XXXXXXXXXXX.XXXXXXXXXXX     94543ms     93360ms     1182ms                             
         XXXXXXXXXXX.XXXXXXXXXXX     87778ms     83832ms     3945ms                             
XXXXXXXXXXX.XXXXXXXXXXX     48675ms     48635ms       40ms                             
            XXXXXXXXXXX.XXXXXXXXXXX     44022ms     44022ms        0ms                             
               XXXXXXXXXXX.XXXXXXXXXXX     29715ms     29715ms        0ms                             
         XXXXXXXXXXX.XXXXXXXXXXX     20737ms      5445ms    15291ms                             
   XXXXXXXXXXX.XXXXXXXXXXX     13962ms     13939ms       22ms      

mongodb bug

在提交工单给阿里云的专家后,正好有人遇到过相似问题,是 mongodb 的 bug。
https://github.com/mongodb/mo…
很遗憾,因为没有在现场再次查看 cpu 的秒级中断,上下文切换数据,我未能本人找到这个 bug。
如果应用 vmstat 来观测,出问题的那一秒,上下文切换和中断会忽然飙到上一秒的 1.8 倍左右。和 mongotop 的异样工夫点齐全吻合。

总结

  • 一瞬间的性能问题,须要更高精度的监控数据来定位。
  • 留神使用率的陷阱,使用率高不代表肯定过载,使用率低也不代表肯定闲暇。
    按分钟计算,磁盘使用率为 %20,能够是前 10 秒使用率为 %100。后 50 秒简直齐全闲暇。这个不能阐明磁盘未过载。当然这种状况下的 await 和读写队列并不会特地低。

正文完
 0