一、背景

本文欲梳理一次mongodb的生产事故，在不确定事故起因的情况下，我们从早上六七点，一直到中午才定位出问题。
持续时间之长，不可谓不是一次惨痛的教训。
首先，我们是第一时间收到了Mongodb数据库监控告警的信息，体现最明显的是cpu使用率达到了100%。（遗漏了其他信息，或者说不同于以往的指标，待下文细说）
其次，客户端应用反馈说后端响应巨慢，无法访问。说明后端服务挂了，此时再使用应用重启这一大招也不好使。

基于这两点，我们无法排查并定位出问题，因为此mongodb数据库集群是一批应用共用。
到底是哪个服务导致数据库性能下降呢？
当然，嫌疑最大的服务，我们很容易第一时间把它排除出去。
排除出去的结果是，并没有让数据库性能恢复，似乎只有重启数据库一条路了。
而由于购买的是阿里云Mongodb数据库服务，重启的权限还没有呢。。。于是拖到很晚的时间，数据库的性能才真正恢复。

二、mongodb副本集

上图为副本集的集群模式示意图（一主二副），实际生产环境中，我们采用的是简配版：一主一副。

三、mongodb主节点

1、cpu使用率

一次删除一张大表的时候，当时删除的数据量有一千万，也出现了cpu飙升至100%的异常。所以，我们遇到这种情况，一般会选择等待。

可以看到主节点的cpu使用率持续在100%

2、 内存使用率

内存飙升，这是跟以往数据库性能变差的一大不同。
可惜，起初只是看到这一现象，并未由此得到什么重要信息。

接下来，我们再看看其他指标，比如操作QPS、网络流量、影响文档数量、GlobalLock等四个指标。

3、操作QPS 和 网络流量

操作QPS和网络流量这这个时间段，发生了陡然降低的现象。
当然，事后分析，可能是后端服务已大面积挂了，导致外网请求进不来。
但是，由于是将近晚上10点，本来也没有多少用户使用量，后者也是可能的，并且是符合日常规律的。

同样，影响文档数量也是急速下降，分析结果同上。

最关键是锁等待的数量剧集上升。

4、影响文档数量 和 GlobalLock

是什么原因到底，在QPS、流量和文档数量都下降的情况下，相当于是没有多少增删改查的情况下，锁数量却上升呢？

四、mongodb副本

还是从cpu指标看，访问量陡然下降，跟主节点的QPS/流量/影响文档数是一致。
可以说，没有太多的排查价值。

五、小结

这里总结下Mongodb监控所得的信息，

上升的指标有：

• cpu
• 内存
• 锁GlobalLock

下降的指标有：

• 操作QPS数
• 网络流量
• 影响文档数量

业务量下降的情况下，或者说客户端请求不到后端服务的情况下， 如何会导致内存飙升以及锁数量剧增呢？

如果遇到这种情况，排查思路应该是什么，以及实际情况又是如何发展的呢？

请见下一篇。