关于mongodb:MongoDB特定场景性能数十倍提升优化实践记一次MongoDB核心集群雪崩故障

1. 问题背景

某外围JAVA长连贯服务应用MongoDB作为次要存储，客户端数百台机器连贯同一MongoDB集群，短期内呈现屡次性能抖动问题，此外，还呈现一次“雪崩”故障，同时流量霎时跌零，无奈主动复原。本文剖析这两次故障的根本原因，包含客户端配置应用不合理、MongoDB内核链接认证不合理、代理配置不全等一系列问题，最终通过多方致力确定问题本源。

该集群有十来个业务接口拜访，每个接口部署在数十台业务服务器下面，拜访该MongoDB机器的客户端总数超过数百台，局部申请一次拉取数十行甚至百余行数据。

该集群为2机房同城多活集群(选举节不耗费太多资源，异地的第三机房来部署选举节点)，架构图如下：

从上图能够看出，为了实现多活，在每个机房都部署有对应代理，对应机房客户端链接对应机房的mongos代理，每个机房多个代理。代理层部署IP:PORT地址列表(留神：不是实在IP地址)如下：

A机房代理地址列表：1.1.1.1:111,2.2.2.2:1111,3.3.3.3:1111

B机房代理地址列表：4.4.4.4:1111,4.4.4.4:2222

A机房三个代理部署在三台不同物理机，B机房2个代理部署在同一台物理机。此外，A机房和B机房为同城机房，跨机房拜访时延能够疏忽。

集群存储层和config server都采纳同样的架构：A机房(1主节点+1从节点) + B机房(2从节点)+C机房(1个选举节点arbiter)，即2(数据节点)+2(数据节点)+1(选举节点)模式。

该机房多活架构能够保障任一机房挂了，对另一机房的业务无影响，具体机房多活原理如下：

1. 如果A机房挂掉，因为代理是无状态节点，A机房挂掉不会影响B机房的代理。
2. 如果A机房挂掉，同时主节点在A机房，这时候B机房的2个数据节点和C机房的选举节点一共三个节点，能够保障新选举须要大于一半以上节点这个条件，于是B机房的数据节点会在短时间内选举出一个新的主节点，这样整个存储层拜访不受任何影响。

本文重点剖析如下6个疑难点：

1. 为什么突发流量业务会抖动？
2. 为什么数据节点没有任何慢日志，然而代理负载缺100%？
3. 为何mongos代理引起数小时的“雪崩”，并且长时间不可复原？
4. 为何一个机房代理抖动，对应机房业务切到另一个机房后，还是抖动？
5. 为何异样时候抓包剖析，客户端频繁建链断链，并且同一个链接建链到断链距离很短？
6. 实践上代理就是七层转发，耗费资源更少，相比mongod存储应该更快，为何mongod存储节点无任何抖动，mongos代理缺有抖动？

2. 故障过程

2.1 业务偶然流量顶峰，业务抖动？

该集群一段时间内有屡次短暂的抖动，当A机房客户端抖动后，发现A机房对应代理负载很高，于是切换A机房拜访B机房代理，然而切换后B机房代理同样抖动，也就是多活切换没有作用，具体过程剖析如下。

2.1.1 存储节点慢日志剖析

首先，剖析该集群所有mongod存储节点零碎CPU、MEM、IO、load等监控信息，发现一切正常，于是剖析每个mongod节点慢日志(因为该集群对时延敏感，因而慢日志调整为30ms)，剖析后果如下：

从上图能够看出，存储节点在业务抖动的时候没有任何慢日志，因而能够判断存储节点一切正常，业务抖动和mongod存储节点无关。

2.1.2 mongos代理剖析

存储节点没有任何问题，因而开始排查mongos代理节点。因为历史起因，该集群部署在其余平台，该平台对QPS、时延等监控不是很全，造成晚期抖动的时候监控没有及时发现。抖动后，迁徙该平台集群到oppo自研的新管控平台，新平台有具体的监控信息，迁徙后QPS监控曲线如下：

每个流量徒增工夫点，对应业务监控都有一波超时或者抖动，如下：

剖析对应代理mongos日志，发现如下景象：抖动工夫点mongos.log日志有大量的建链接和断链接的过程，如下图所示：

从上图能够看出，一秒钟内有几千个链接建设，同时有几千个链接断开，此外抓包发现很多链接短期内即断开链接，景象如下(断链工夫-建链工夫=51ms, 局部100多ms断开)：

对应抓包如下：

此外，该机器代理上客户端链接低峰期都很高，甚至超过失常的QPS值，QPS大概7000-8000，然而conn链接缺高达13000，mongostat获取到监控信息如下：

2.1.3 代理机器负载剖析

每次突发流量的时候，代理负载很高，通过部署脚本定期采样，抖动工夫点对应监控图如下图所示：

从上图能够看出，每次流量顶峰的时候CPU负载都十分的高，而且是sy%负载，us%负载很低，同时Load甚至高达好几百，偶然甚至过千。

2.1.4 抖动剖析总结

从下面的剖析能够看出，某些工夫点业务有突发流量引起零碎负载很高。根因真的是因为突发流量吗？其实不然，请看后续剖析，这其实是一个谬误论断。没过几天，同一个集群雪崩了。

于是业务梳理突发流量对应接口，梳理进去后下掉了该接口，QPS监控曲线如下：

为了缩小业务抖动，因而下掉了突发流量接口，尔后几个小时业务不再抖动。当下掉突发流量接口后，咱们还做了如下几件事件：

1. 因为没找到mongos负载100%真正起因，于是每个机房扩容mongs代理，放弃每个机房4个代理，同时保障所有代理在不同服务器，通过分流来尽量减少代理负载。
2. 告诉A机房和B机房的业务配置上所有的8个代理，不再是每个机房只配置对应机房的代理(因为第一次业务抖动后，咱们剖析MongoDB的java sdk，确定sdk平衡策略会主动剔除申请时延高的代理，下次如果某个代理再出问题，也会被主动剔除)。
3. 告诉业务把所有客户端超时工夫进步到500ms。

然而，心里始终有很多纳闷和悬念，次要在以下几个点：

1. 存储节点4个，代理节点5个，存储节点无任何抖动 ，反而七层转发的代理负载高？
2. 为何抓包发现很多新连贯几十ms或者一百多ms后就断开连接了？频繁建链断链？
3. 为何代理QPS只有几万，这时代理CPU耗费就十分高，而且全是sy%零碎负载？以我多年中间件代理研发教训，代理耗费的资源很少才对，而且CPU只会耗费us%，而不是sy%耗费。

2.2 同一个业务几天后“雪崩”了

好景不长，业务下掉突发流量的接口没过几天，更重大的故障呈现了，机房B的业务流量在某一时刻间接跌0了，不是简略的抖动问题，而是业务间接流量跌0，零碎sy%负载100%，业务简直100%超时重连。

2.2.1 机器系统监控剖析

机器CPU和零碎负载监控如下：

从上图能够看出，简直和后面的突发流量引起的零碎负载过高景象统一，业务CPU sy%负载100%，load很高。登陆机器获取top信息，景象和监控统一。

同一时刻对应网络监控如下：

磁盘IO监控如下：

从下面的系统监控剖析能够看出，出问题的时间段，零碎CPU sy%、load负载都很高，网络读写流量简直跌0，磁盘IO一切正常，能够看出整个过程简直和之前突发流量引起的抖动问题完全一致。

2.2.2 业务如何复原

第一次突发流量引起的抖动问题后，咱们扩容所有的代理到8个，同时告诉业务把所有业务接口配置上所有代理。因为业务接口泛滥，最终B机房的业务没有配置全副代理，只配置了原先的两个处于同一台物理机的代理(4.4.4.4:1111,4.4.4.4:2222)，最终触发MongoDB的一个性能瓶颈(详见前面剖析)，引起了整个MongoDB集群”雪崩”

最终，业务通过重启服务，同时把B机房的8个代理同时配置上，问题得以解决。

2.2.3 mongos代理实例监控剖析

剖析该时间段代理日志，能够看出和2.1同样得景象，大量的新键连贯，同时新连贯在几十ms、一百多ms后又敞开连贯。整个景象和之前剖析统一，这里不在统计分析对应日志。

此外，剖析过后的代理QPS监控，失常query读申请的QPS拜访曲线如下，故障时间段QPS简直跌零雪崩了：

Command统计监控曲线如下：

从下面的统计能够看出，当该代理节点的流量故障工夫点有一波尖刺，同时该工夫点的command统计霎时飙涨到22000(理论可能更高，因为咱们监控采样周期30s,这里只是平均值)，也就是霎时有2.2万个连贯霎时进来了。Command统计实际上是db.ismaster()统计，客户端connect服务端胜利后的第一个报文就是ismaster报文，服务端执行db.ismaster()后应答客户端，客户端收到后开始正式的sasl认证流程。

失常客户端拜访流程如下：

1. 客户端发动与mongos的链接
2. Mongos服务端accept接管链接后，链接建设胜利
3. 客户端发送db.isMaster()命令给服务端
4. 服务端应答isMaster给客户端
5. 客户端发动与mongos代理的sasl认证(屡次和mongos交互)
6. 客户端发动失常的find()流程

客户端SDK链接建设胜利后发送db.isMaster()给服务端的目标是为了负载平衡策略和判断节点是什么类型，保障客户端疾速感知到拜访时延高的代理，从而疾速剔除往返时延高的节点，同时确定拜访的节点类型。

此外，通过提前部署的脚本,该脚本在零碎负载高的时候主动抓包，从抓包剖析后果如下图所示：

上图时序剖析如下：

1. 11:21:59.506174链接建设胜利
2. 11:21:59.506254 客户端发送db.IsMaster()到服务端
3. 11:21:59.656479 客户端发送FIN断链申请
4. 11:21:59.674717 服务端发送db.IsMaster()应答给客户端
5. 11:21:59.675480 客户端间接RST

第3和第1个报文之间相差大概150ms，最初和业务确定该客户端IP对应的超时工夫配置，确定就是150ms。此外，其余抓包中有相似40ms、100ms等超时配置，通过对应客户端和业务确认，确定对应客户端业务接口超时工夫配置的就是40ms、100ms等。因而，联合抓包和客户端配置，能够确定当代理超过指定超时工夫还没有给客户端db.isMaster()返回值，则客户端立马超时，超时后立马发动重连申请。

总结： 通过抓包和mongos日志剖析，能够确定链接建设后疾速断开的起因是：客户端拜访代理的第一个申请db.isMaster()超时了，因而引起客户端重连。重连后又开始获取db.isMaster()申请，因为负载CPU 100%, 很高，每次重连后的申请都会超时。其中配置超时工夫为500ms的客户端，因为db.isMaster()不会超时，因而后续会走sasl认证流程。

因而能够看出，零碎负载高和重复的建链断链无关，某一时刻客户端大量建设链接(2.2W)引起负载高，又因为客户端超时工夫配置不一，超时工夫配置得比拟大得客户端最终会进入sasl流程，从内核态获取随机数，引起sy%负载高，sy%负载高又引起客户端超时，这样整个拜访过程就成为一个“死循环”，最终引起mongos代理雪崩。

2.3 线下模仿故障

到这里，咱们曾经大略确定了问题起因，然而为什么故障突发工夫点那一瞬间2万个申请就会引起sy%负载100%呢，实践上一秒钟几万个链接不会引起如此重大的问题，毕竟咱们机器有40个CPU。因而，剖析重复建链断链为何引起零碎sy%负载100%就成为了本故障的关键点。

2.3.1 模仿故障过程

模仿频繁建链断链故障步骤如下：

1. 批改mongos内核代码，所有申请全副延时600ms
2. 同一台机器起两个同样的mongos，通过端口辨别
3. 客户端启用6000个并发链接，超时工夫500ms

通过下面的操作，能够保障所有申请超时，超时后客户端又会立马开始从新建链，再次建链后拜访MongoDB还会超时，这样就模仿了重复建链断链的过程。此外，为了保障和雪崩故障环境统一，把2个mongos代理部署在同一台物理机。

2.3.2 故障模拟测试后果

为了保障和故障的mongos代理硬件环境统一，因而抉择故障同样类型的服务器，并且操作系统版本一样(2.6.32-642.el6.x86_64)，程序都跑起来后，问题立马浮现：

因为出故障的服务器操作系统版本linux-2.6过低，因而狐疑可能和操作系统版本有问题，因而降级同一类型的一台物理机到linux-3.10版本，测试后果如下：

从上图能够看出，客户端6000并发重复重连，服务端压力失常，所有CPU耗费在us%，sy%耗费很低。用户态CPU耗费3个CPU，内核态CPU耗费简直为0，这是咱们期待的失常后果，因而感觉该问题可能和操作系统版本有问题。

为了验证更高并重复建链断链在Linux-3.10内核版本是否有2.6版本同样的sy%内核态CPU耗费高的问题，因而把并发从6000晋升到30000，验证后果如下：

测试后果： 通过批改MongoDB内核版本成心让客户端超时重复建链断链，在linux-2.6版本中，1500以上的并发重复建链断链零碎CPU sy% 100%的问题即可浮现。然而，在Linux-3.10版本中，并发到10000后，sy%负载逐渐减少，并发越高sy%负载越高。

总结： linux-2.6零碎中，MongoDB只有每秒有几千的重复建链断链，零碎sy%负载就会靠近100%。Linux-3.10，并发20000重复建链断链的时候，sy%负载能够达到30%，随着客户端并发减少，sy%负载也相应的减少。Linux-3.10版本相比2.6版本针对重复建链断链的场景有很大的性能改善，然而不能解决基本问题。

2.4 客户端重复建链断链引起sy% 100%根因

为了剖析%sy零碎负载高的起因，装置perf获取零碎top信息，发现所有CPU耗费在如下接口：

从perf剖析能够看出，cpu 耗费在_spin_lock_irqsave函数，持续剖析内核态调用栈，失去如下堆栈信息：

– 89.81% 89.81% [kernel] [k] _spin_lock_irqsave ▒

– _spin_lock_irqsave ▒

– mix_pool_bytes_extract ▒

– extract_buf ▒

extract_entropy_user ▒

urandom_read ▒

vfs_read ▒

sys_read ▒

system_call_fastpath ▒

0xe82d

下面的堆栈信息阐明，MongoDB在读取 /dev/urandom ，并且因为多个线程同时读取该文件，导致耗费在一把spinlock上。

到这里问题进一步清朗了，故障root case 不是每秒几万的连接数导致sys 过高引起。根本原因是每个mongo客户端的新链接会导致MongoDB后端新建一个线程，该线程在某种状况下会调用urandom_read 去读取随机数/dev/urandom ，并且因为多个线程同时读取，导致内核态耗费在一把spinlock锁上，呈现cpu 高的景象。

2.5 MongoDB内核随机数优化

2.5.1 MongoDB内核源码定位剖析

下面的剖析曾经确定，问题本源是MongoDB内核多个线程读取/dev/urandom随机数引起，走读MongoDB内核代码，发现读取该文件的中央如下：

下面是生成随机数的外围代码，每次获取随机数都会读取”/dev/urandom”系统文件，所以只有找到应用该接口的中央即可即可剖析出问题。

持续走读代码，发现次要在如下中央：

//服务端收到客户端sasl认证的第一个报文后的解决，这里会生成随机数
//如果是mongos，这里就是接管客户端sasl认证的第一个报文的解决流程
Sasl_scramsha1_server_conversation::_firstStep(...) {
 ... ...
 unique_ptr<SecureRandom> sr(SecureRandom::create());
 binaryNonce[0] = sr->nextInt64();
 binaryNonce[1] = sr->nextInt64();
 binaryNonce[2] = sr->nextInt64();
 ... ...
}
//mongos相比mongod存储节点就是客户端，mongos作为客户端也须要生成随机数
SaslSCRAMSHA1ClientConversation::_firstStep(...) {
 ... ...
 unique_ptr<SecureRandom> sr(SecureRandom::create());
 binaryNonce[0] = sr->nextInt64();
 binaryNonce[1] = sr->nextInt64();
 binaryNonce[2] = sr->nextInt64();
 ... ...
}

2.5.2 MongoDB内核源码随机数优化

从2.5.1剖析能够看出，mongos解决客户端新连贯sasl认证过程都会通过”/dev/urandom”生成随机数，从而引起零碎sy% CPU过高，咱们如何优化随机数算法就是解决本问题的要害。

持续剖析MongoDB内核源码，发现应用随机数的中央很多，其中有局部随机数通过用户态算法生成，因而咱们能够采纳同样办法，在用户态生成随机数，用户态随机数生成外围算法如下：

class PseudoRandom {
 ... ...
 uint32_t _x;
 uint32_t _y;
 uint32_t _z;
 uint32_t _w;
}

该算法能够保障产生的数据随机散布，该算法原理详见：

http://en.wikipedia.org/wiki/…

也能够查看如下git地址获取算法实现：MongoDB随机数生成算法正文

总结： 通过优化sasl认证的随机数生成算法为用户态算法后，CPU sy% 100%的问题得以解决，同时代理性能在短链接场景下有了数倍/数十倍的性能晋升。

3. 问题总结及疑难解答

从下面的剖析能够看出，该故障由多种因素连环触发引起，包含客户端配置使用不当、MongoDB服务端内核极其情况异常缺点、监控不全等。总结如下：

1. 客户端配置不对立，同一个集群多个业务接口配置千奇百怪，超时配置、链接配置各不相同，减少了抓包排查故障的难度，超时工夫设置太小容易引起重复重连。
2. 客户端须要配全所有mongos代理，这样当一个代理故障的时候，客户端SDK默认会剔除该故障代理节点，从而能够保障业务影响最小，就不会存在单点问题。
3. 同一集群多个业务接口应该应用同一配置核心对立配置，防止配置不对立。
4. MongoDB内核的新连贯随机算法存在重大缺点，在极其状况下引起重大性能抖动，甚至业务“雪崩”。

剖析到这里，咱们能够答复第1章节的6个疑难点了，如下：

为什么突发流量业务会抖动？

答：因为业务是java业务，采纳链接池形式链接mongos代理，当有突发流量的时候，链接池会减少链接数来晋升拜访MongoDB的性能，这时候客户端就会新增链接，因为客户端泛滥，造成可能霎时会有大量新连贯和mongos建链。链接建设胜利后开始做sasl认证，因为认证的第一步须要生成随机数，就须要拜访操作系统”/dev/urandom”文件。又因为mongos代理模型是默认一个链接一个线程，所以会造成霎时多个线程拜访该文件，进而引起内核态sy%负载过高。

为何mongos代理引起“雪崩”，流量为何跌零不可用？

答：起因客户端某一时刻可能因为流量忽然有减少，链接池中链接数不够用，于是减少和mongos代理的链接，因为是老集群，代理还是默认的一个链接一个线程模型，这样霎时就会有大量链接，每个链接建设胜利后，就开始sasl认证，认证的第一步服务端须要产生随机数，mongos服务端通过读取”/dev/urandom”获取随机数，因为多个线程同时读取该文件触发内核态spinlock锁CPU sy% 100%问题。因为sy%零碎负载过高，因为客户端超时工夫设置过小，进一步引起客户端拜访超时，超时后重连，重连后又进入sasl认证，又加剧了读取”/dev/urandom”文件，如此重复循环继续。

此外，第一次业务抖动后，服务端扩容了8个mongos代理，然而客户端没有批改，造成B机房业务配置的2个代理在同一台服务器，无奈利用mongo java sdk的主动剔除负载高节点这一策略，所以最终造成”雪崩”。

为什么数据节点没有任何慢日志，然而代理负载却CPU sy% 100%？

答：因为客户端java程序间接拜访的是mongos代理，所以大量链接只产生在客户端和mongos之间，同时因为客户端超时工夫设置太短(有接口设置位几十ms，有的接口设置位一百多ms，有的接口设置位500ms)，就造成在流量峰值的时候引起连锁反应(突发流量零碎负载高引起客户端疾速超时，超时后疾速重连，进一步引起超时，有限死循环)。Mongos和mongod之间也是链接池模型，然而mongos作为客户端拜访mongod存储节点的超时很长，默认都是秒级别，所以不会引起重复超时建链断链。

为何A机房代理抖动的时候，A机房业务切到B机房后，还是抖动？

答：当A机房业务抖动，业务切换到B机房的时候，客户端须要从新和服务端建设链接认证，又会触发大量重复建链断链和读取随机数”/dev/urandom”的流程，所以最终造成机房多活失败。

为何异样时候抓包剖析，客户端频繁建链断链，并且同一个链接建链到断链距离很短？

答：频繁建链断链的根本原因是零碎sy%负载高，客户端极短时间内建设链接后又端口的起因是客户端配置超时工夫太短。

实践上代理就是七层转发，耗费资源更少，相比mongod存储应该更快，为何mongod存储节点无任何抖动，mongos代理却有重大抖动？

答：因为采纳分片架构，所有mongod存储节点后面都有一层mongos代理，mongos代理作为mongod存储节点的客户端，超时工夫默认秒级，不会呈现超时景象，也就不会呈现频繁的建链断链过程。

如果MongoDB集群采纳一般复制集模式，客户端频繁建链断链是否可能引起mongod存储节点同样的“雪崩”？

答：会。如果客户端过多，操作系统内核版本过低，同时超时工夫配置过段，间接拜访复制集的mongod存储节点，因为客户端和存储节点的认证过程和与mongos代理的认证过程一样，所以还是会触发引起频繁读取”/dev/urandom”文件，引起CPU sy%负载过高，极其状况下引起雪崩。

4. “雪崩”解决办法

从下面的一系列剖析，问题在于客户端配置不合理，加上MongoDB内核认证过程读取随机数在极其状况下存在缺点，最终造成雪崩。如果没有MongoDB内核研发能力，能够通过规范化客户端配置来防止该问题。当然，如果客户端配置规范化，同时MongoDB内核层面解决极其状况下的随机数读取问题，这样问题能够失去彻底解决。

4.1 JAVA SDK 客户端配置规范化

在业务接口很多，客户端机器很多的业务场景，客户端配置肯定要做到如下几点：

1. 超时工夫设置为秒级，防止超时工夫设置过端引起重复的建链断链。
2. 客户端须要配置所有mongos代理地址，不能配置单点，否则流量到一个mongos很容易引起霎时流量峰值的建链认证。
3. 减少mongos代理数量，这样能够分流，保障同一时刻每个代理的新键链接尽可能的少，客户端在多代理配置时，默认是平衡流量散发的，如果某个代理负载高，客户端会主动剔除。

如果没有MongoDB内核源码研发能力，能够参考该客户端配置办法，同时淘汰linux-2.6版本内核，采纳linux-3.10或者更高版本内核，基本上能够躲避踩同样类型的坑。

4.2 MongoDB内核源码优化（摈弃内核态获取随机数，抉择用户随机数算法）

详见2.5.2 章节。

4.3 PHP短链接业务，如何躲避踩坑

因为PHP业务属于短链接业务，如果流量很高，不可避免的要频繁建链断链，也就会走sasl认证流程，最终多线程频繁读取”/dev/urandom”文件，很容易引起后面的问题。这种状况，能够采纳4.1 java客户端相似的标准，同时不要应用低版本的Linux内核，采纳3.x以上内核版本，就能够躲避该问题的存在。

5. MongoDB内核源码设计与实现剖析

本文相干的MongoDB线程模型及随机数算法实现相干源码剖析如下：

MongoDB动静线程模型源码设计与实现剖析：

https://github.com/y123456yz/…

MongoDB一个链接一个线程模型源码设计与实现剖析：

https://github.com/y123456yz/…

MongoDB内核态及用户态随机数算法实现剖析：

https://github.com/y123456yz/…