vlambda博客
学习文章列表

调整cacheSize从120G到50G后，如果脏数据比例达到5%，则极端情况下如果淘汰速度跟不上客户端写入速度，这样还是容易引起I/O瓶颈，最终造成阻塞。

解决办法：如何进一步减少持续性I/O写入，也就是如何平衡cache内存和磁盘I/O的关系成为问题关键所在。从上表中可以看出，如果脏数据及总内占用存达到一定比例，后台线程开始选择page进行淘汰写盘，如果脏数据及内存占用比例进一步增加，那么用户线程就会开始做page淘汰，这是个非常危险的阻塞过程，造成用户请求验证阻塞。平衡cache和I/O的方法: 调整淘汰策略，让后台线程尽早淘汰数据，避免大量刷盘，同时降低用户线程阀值，避免用户线程进行page淘汰引起阻塞。优化调整存储引起配置如下:

 eviction_target: 75%

 eviction_trigger：97%

 eviction_dirty_target: %3

 eviction_dirty_trigger：25%

 evict.threads_min：8

 evict.threads_max：12

总体思想是让后台evict尽量早点淘汰脏页page到磁盘，同时调整evict淘汰线程数来加快脏数据淘汰，调整后mongostat及客户端超时现象进一步缓解。

通过大量的线下测试以及服务器厂商的配合，nvme的ssd io瓶颈问题得以解决，经过和厂商确认分析，最终定位到IO问题是linux内核版本不匹配引起，如果大家nvme ssd盘有同样问题，记得升级linux版本到3.10.0-957.27.2.el7.x86_64版本，升级后nvme ssd的IO能力达到近2G/s写入。

说明: 从本节开始，我们的服务器分为两种：1. 低IO服务器，也就是没有做操作系统升级的服务器，IO写入能力500M/s，2. 高IO服务器，也就是操作系统升级后的服务器，IO写入能力近2G/s.。

于是考虑把该分片集群的主节点全部迁移到操作系统升级后的高IO服务器(为了谨慎，我们只替换了分片主节点，从节点还是老的未升级的低IO服务器)，该服务器io写入能达到近2G/s(注意:只迁移了主节点，从节点还是在之前的IO-500M/s的低IO服务器)，具体的操作过程在后面章节会描述，详见3.3章节。迁移完成后，发现性能得到了进一步提升，时延迟降低到平均2-4ms/s，几个不同业务接口看到的时延监控如下图所示：

从上图时延可以看出，迁移主节点到操作系统升级后的高IO机器后，时延进一步降低到平均2-4ms。

虽然时延降低到了平均2-4ms，但是还是有很多几十ms的尖刺，因此我们需要进一步的优化分析。

在前面的分析中，我们在定位nvme ssd硬件IO问题的过程中，和厂商一起分析发现IO问题是由于操作系统版本不对引起，于是开始对线上的主从mongod实例的服务器硬件进行升级，升级后开始替换线上该集群的实例。具体操作过程如下:

1. 为了验证IO升级后的机器，我们替换一个分片的从节点为升级操作系统后的高IO服务器(IO问题得以解决，IO能力从之前的500M/s写入达到了近2G/s，我们称IO升级后的服务器为高IO服务器，未升级的服务器为低IO服务器)，替换后通过iostat可以看到该从节点的IO 100%问题得到了很大程度的缓解，不会出现持续性IO跌0问题。

2. 在第1步的从节点在高IO服务器跑了一周后，我们确定升级后的高IO服务器运行稳定，为了谨慎起见，我们虽然确定该高IO服务器在从节点运行没有问题，但是我们需要进一步在主节点验证是否稳定，于是我们做了一次主从切换，该高IO服务器变为主节点运行，也就是集群中某个分片的主节点服务器变为了高IO服务器，但是从节点还是低IO服务器。

3. 当第2步的主节点在高IO服务器跑了数周后，我们确定主节点在高IO服务器运行正常，于是我们得下结论: 升级后的服务器运行稳定。

4. 确定高IO服务器没问题后，我们开始批量替换mongod实例到该服务器。为了保险起见，毕竟只验证了一台高IO服务器在主从运行都没问题，于是我们考虑只把整个集群的主节点替换为高IO服务器(当时我认为客户端都是用的默认配置，数据写到主节点就会返回OK，虽然从节点IO慢，但是还是可以追上oplog速度的，这样客户端时延不会因为以前主节点IO有问题而抖动)。

为了谨慎保险起见，通过上面的硬件替换升级过程，我们只替换了所有分片的主节点，替换升级前后架构发生了变化，原有集群硬件架构如下图所示：

所有分片主节点硬件升级后的架构图如下图所示：

从上图可知，新的集群架构，主从节点服务器IO能力有比较大的差距。最开始我认为业务方默认没有设置WriteConncern，也就是默认写入到Primary就向客户端发送确认，因此不会影响业务写入。

所有分片主节点升级为高IO服务器后，多个业务接口的时间访问延迟降到了平均2-4ms左右，但是在超大流量冲击的时候，还是有几十ms的尖刺，我选取一个抖动比较典型的接口时延为例，如下图所示：

从上图可以看出，特别是在大流量冲击的时间点，尖刺越明显。

在上一节，我们替换了分片的所有主节点为高IO服务器，从节点还是以前未升级的低IO服务器。由于业务方默认没有设置WriteConncern，因此认为客户端写到主成功就会返回客户端OK，即使从服务器性能差也不会影响客户端写主。

在升级主服务器后，我继续优化存储引擎把eviction_dirty_trigger：25%调整到了30%。

由于受到超大流量的高并发冲击，会从平峰期的几十万TPS瞬间飙升到百万级别，而且该毛刺几乎每天都会出现好几次，比较容易复现。于是提前部署好mongostat监控所有实例，同时在每个服务器上用Iostat监控实时的IO状况，同时编写脚本实时采集db.serverstatus()、db.printSlaveReplicationInfo()、db.printReplicationInfo()等集群重要信息。

当某个时间点监控出现毛刺后，于是开始分析mongostat，我们发现一个问题，即使在平峰期，脏数据比例也会持续增长到阀值(30%)，我们知道当脏数据比例超过eviction_dirty_trigger：30%阀值，用户线程就会进行evict淘汰，这样用户线程就会阻塞直到腾出内存空间，因此淘汰刷盘过程业务访问很慢。分析平峰期毛刺时间点对应的mongostat监控，发现如下情况:

从上图可以看出，集群TPS才40-50万左右的时候某个分片的主节点出现了脏数据达到eviction_dirty_trigger：30%阀值，于是整个集群访问时延就会瞬间增加，原因是一个分片的用户线程需要刷盘，导致这个分片的访问时延上升(实际上其他分片的访问时延还是正常的)，最终把整体平均时延拉上去了。

为什么普通平峰期也会有抖动？这很明显不科学。

于是获取出问题的主节点的一些监控信息，得出以下结论：

1. IO正常，IO不是瓶颈。

2. 分析抖动的时候的系统top负载，负载正常。

3. 该分片的TPS才4万左右，显然没到到分片峰值。

4. db.printSlaveReplicationInfo()看到主从延迟较高。

当客户端时延监控发现时间延迟尖刺后，我们发现主节点所有现象一切正常，系统负载、IO、TPS等都没有到达瓶颈，但是有一个唯一的异常，就是主从同步延迟持续性增加，如下图所示：

同时对应低IO服务器的从节点上面的io状况如下图:

从节点的IO性能一塌乌涂，这也正是主从延迟增加的根源。

 从上图可以看出在时延尖刺的同样时间点，主从延迟超大。于是怀疑时延尖刺可能和从节点拉取Oplog速度有关系，于是把整个mongostat、iostat、top、db.printSlaveReplicationInfo()、db.serverstatus()等监控持续跑了两天，记录下了两天内的一些核心系统和mongo监控指标。

两天后，对着客户端时延尖刺时间点分析对应监控数据，发现一个共同的现象，尖刺出现时间点和脏数据eviction_dirty_trigger超过阀值时间点一致，同时主从延迟在这个时间点都有很大的延迟。

到这里，我越来越怀疑问题和从节点拉取oplog速度有关。之前认为业务方默认没有设置WriteConncern，也就是默认写入到Primary就向客户端发送确认，可能应答客户端前还有其他流程会影响服务的返回OK给客户端。于是查看官方mongodb-3.6的ProductionNotes，从中发现了如下信息：

从ProductionNotes可以看出，mongodb-3.6默认启用了 read concern "majority"功能，于是怀疑抖动可能和该功能有关。为了避免脏读，mongodb增加了该功能，启用该功能后，mongodb为了确保带有带有参数readConcern("Majority")的客户端读取到的数据确实是同步到大多数实例的数据，因此mongodb必须在内存中借助snapshot 及主从通信来维护更多的版本信息，这就增加了wiredtiger存储引擎对内存的需求。由于从节点是低IO服务器，很容易造成阻塞，这样拉取oplog的速度就会跟不上进度，造成主节点消耗大量的内存来维护快照信息，这样就会导致大量的内存消耗，最终导致脏数据瞬间剧增，很快达到eviction_dirty_trigger阀值，业务也因此抖动。

说一个小插曲，因为mongodb-3.6默认开启enableMajorityReadConcern功能，我们在这个过程中出现过几次严重的集群故障，业务流量有段时间突然暴涨，造成时延持续性达到几千ms，写入全部阻塞，现象如下:

该问题的根源也是因为enableMajorityReadConcern功能引起，由于从节点严重落后主节点，导致主节点为了维护各种snapshot快照，消耗大量内存，同时从节点和主节点的oplog延后，导致主节点维护了更多的内存版本，脏数据比例持续性增长，直到从节点追上oplog。由于我们的业务不需要readConcert功能，因此我们考虑禁用该功能(配置文件增加配置replication.enableMajorityReadConcern=false)。

鉴于篇幅，enableMajorityReadConcern及主从硬件IO能力不足引起的严重业务故障，本篇不做详细的分析，后期会写一篇专门的《百万级高并发mongodb集群性能优化采坑记》中做分享，除了ReadConcern采坑，还有其他好几个核心采坑点，敬请关注。

此外，后续会专门写一篇ReadConcern的原理及代码实现分析文章，敬请关注。

除了通过replication.enableMajorityReadConcern=false在配置文件中禁用ReadConcern Majority功能，我们继续把所有分片的从节点由之前的低IO服务器替换为升级后的高IO服务器，升级后所有主从硬件资源性能完全一样，升级后集群分片架构如下图所示：

通过禁用enableMajorityReadConcern功能，并统一主从服务器硬件资源后，查看有抖动的一个接口的时间延迟，如下图所示：

从上图可以看出，通过MajorityReadConcern功能并且替把所有从节点的低IO服务器做系统升级后，业务时间延迟抖动的峰值进一步降低了，从平均2-4ms降低到了1ms左右，同时，峰值毛刺从前面第3节中的80ms降低到了现在的峰值40ms左右。

此外，4.1节提到的脏数据持续性突破eviction_dirty_trigger阀值引起客户端时延飙涨到几千ms的问题得以彻底解决。

总结: MajorityReadConcern功能禁用并升级从节点到高IO服务器后，总体收益如下：

1. 平均时延从2-4ms降低到1ms左右。

2. 峰值时延毛刺从80ms降低到40ms。

3. 之前出现的脏数据比例突破30%飙涨到50%的问题彻底解决。

4. 尖刺持续时间变短。

通过前面的条优化，我们发现有一个业务接口还是偶尔有40ms时延尖刺，分析发现主要是eviction_dirty_trigger达到了我们配置的阀值，业务线程开始淘汰page cache，这样就造成业务线程很慢，最终导致平均时延尖刺。

为了进一步减缓时延尖刺，我们继续在之前基础上对存储引擎调优，调整后配置如下：

    eviction_target:75%

   eviction_trigger：97%

   eviction_dirty_target: %3

   eviction_dirty_trigger：30%

   evict.threads_min：14

   evict.threads_max：18

   checkpoint=(wait=20,log_size=1GB)

经过此轮的存储引擎调优后，该业务的核心接口时延进一步好转，时延尖刺相比之前有了进一步的改善，时延最大尖刺时间从前面的45ms降低到了35ms，同时尖刺出现的频率明显降低了，如下图所示:

从此图可以看出，在个别时间点还是有一次时延尖刺，对照该尖刺的时间点分析提前部署好的mongostat和iostat监控，得到如下信息：

从上图可以看出，在峰值TPS百万级别的时候，部分节点evict淘汰速率已经跟不上写入速度，因此出现了用户线程刷盘的情况。

在这个时间点分析对应机器的系统负载、磁盘io状况、内存状况等，发现系统负载、比较正常，但是对应服务器磁盘IO偏高，如下图所示：