MongoDB疑难解析：为何升级以后负载升高了？

本文是“我和MongoDB的故事”征文比赛的二等奖得主李鹏冲的文章。下面咱们一块儿来欣赏下。

问题

近期线上一个三分片集群从 3.2 版本升级到 4.0 版本之后，集群节点的 CPU 的负载升高了不少（10% -> 40%）, 除了版本的升级，项目逻辑和操做量均无变化。关闭 Balancer 之后 CPU 负载回归正常，稳定在 10% 如下。为此，只能常常关闭当前正在写入表的 balancer , 每周二打开 balancer 开启均衡，在此期间节点的 CPU 负载持续稳定在 40% 。集群有 3 个分片，除了 MongoDB 版本的变化，项目自己的逻辑无任何变化。那么升级之后 CPU 负载较大变化的背后是什么缘由呢？

监控与日志

首先能够明确，升级之后 CPU 负载升高和 balancer 迁移数据有关。观察升级之后 4.0 版本，周二打开 balancer 期间的负载状况和 mongostat 结果：

能够发现，CPU 负载升高和 delete 数据的状况很吻合。而迁移数据数据以后源节点须要删除迁移走的数据，因此确定有大量的 delete 。迁移数据以后的删除也会有以下的日志：

53094:2019-10-08T10:09:24.035199+08:00 I SHARDING [Collection Range Deleter] No documents remain to delete in dt2log.tbl_log_item_20191001 range [{ _id: -3074457345618258602 }, { _ id: -3033667061349287050 })
53095:2019-10-08T10:09:24.035222+08:00 I SHARDING [Collection Range Deleter] Waiting for m ajority replication of local deletions in dt2log.tbl_log_item_20191001 range [{ _id: -3074 457345618258602 }, { _id: -3033667061349287050 })
53096:2019-10-08T10:09:24.035274+08:00 I SHARDING [Collection Range Deleter] Finished dele ting documents in dt2log.tbl_log_item_20191001 range [{ _id: -3074457345618258602 }, { _id
-3033667061349287050 })

因此从监控和日志判断， CPU 负载较高主要是由于迁移数据以后的删除致使。并且集群的表都是 {_id : hashed} 分片类型的表，数据量较大，可是每条数据较小，平均每一个 chunk 10w+ 的文档数，删除数据速度约 200-300/s ，因此移动一个 chunk 致使的删除就会持续 10 分钟左右。

统计最近2个周期，开启 balancer 之后 moveChunk 的状况：

从上表可知此场景下， {_id : hashed} 分片类型集合数据基本已经均匀了，没必要重启开启 balancer 。由于 每一个chunk 文档数较多，删除会比较耗资源。

关闭表的 balancer 能够解决升级以后负载升高的问题，可是居然是为什么升级到 4.0 以后 CPU 负载较高, 而 3.2 版本稳定在低位呢？这只有多是一个缘由：4.0 版本更频繁的发生 moveChunk, 持续的删除数据致使 CPU 负载一直较高；3.2 版本较少的发生 moveChunk，不用删除数据因此负载很低。

因此本次问题的根本是: 4.0 版本和 3.2 版本的 balancer 与 moveChunk 的逻辑是否有差异？一样的操做，为何 4.0版本的集群会有较多的 moveChunk ？

撸代码：splitChunk、balancer与moveChunk

当经过 mongos 发生插入和更新删除操做时，mongos 会估算对应 chunks 的数据量的大小，知足条件会触发splitChunk 的操做，splitChunk 以后可能会致使集群的 chunk 分布不均匀。balancer 检测数据的分布状况，当数据分配不均匀时，发起 moveChunk 任务，将数据从 chunks 较多的分片迁移到 chunks 较少的分片，迁移以后源节点会异步删除迁移走的 chunk 数据。

3.2 版本和 4.0 版本，此部分逻辑最大的区别就是, 3.2 版本 balancer 在 mongos，4.0 版本在 config（3.4版本开始)，moveChunk 过程和删除数据的逻辑基本没有差别。

splitChunk

split chunks 通常是在插入、更新、删除数据时，由 mongos 发出到分片的 splitVector 命令，此时分片才会判断是否须要 split 。可是 mongos 并不知道每一个 chunk 真正的数据量，是利用一个简单的估算算法判断的。

• 启动时，mongos 默认每一个 chunk 的原始大小为 0-1/5 maxChunkSize 范围取个随机值 ；

• 以后 chunk 内数据，每次 update/insert 操做时，chunkSize = chunkSize + docSize；

• 当 chunkSize > maxChunkSize/5 时，触发一次可能 split chunk 的操做； 到 分片mongod 执行 splitVector命令 ，splitVector 命令返回 chunk 的分割点，若是返回为空那么不须要 split ，不然 继续 splitChunk。

也就是说，splitChunk 操做有滞后性，即便数据分布均衡，也有可能 splitChunk 执行时间的差别致使 chunks 分布存在中间的不均匀状态，致使大量的 moveChunk 。

balancer

不管 3.2 仍是 4.0 的 balancer ，默认的检测周期为 10s , 若是发生了 moveChunk ，检测周期为 1s 。balancer 基本过程也大体相同：

• config.shards 读取分片信息 ;

• config.collections 读取全部集合信息，而且随机排序保存到一个数组中；

• 对每一个集合从 config.chunks 读取 chunks 的信息；

含有最多 chunks 数量 （maxChunksNum）的分片为源分片，含有最少 chunks 数量(minChunksNum)的分片为目的分片; 若是 maxChunksNum – minChunksNum 大于迁移的阈值 （threshold）， 那么就是不均衡状态，须要迁移，源分片的 chunks 第一个 chunk 为待迁移的 chunk ，构造一个迁移任务（源分片，目的分片，chunk）。

每次 balancer 会检测全部集合的状况，每一个集合最多一个迁移任务 ; 并且构造迁移任务时，若是某个集合含有最多数量的分片或者最少数量 chunks 的分片，已经属于某一个迁移任务，那么此集合本轮 balancer 不会发生迁移。最后，本次检测出的迁移任务完成之后才开始下次 balancer 过程。

balancer 过程当中，会对集合作一次随机排序，当有多个集合的数据须要均衡时，迁移时也是随机的，并非迁移完一个集合开始下一个集合。

重点关注上述的迁移阈值，就是这个迁移的阈值 threshold 在 3.2 和 4.0 版本有所不一样。

3.2 版本, chunks 数量小于 20 的时候为 2， 小于 80 的时候为 4， 大于 80 的时候为 8 。也就是说假设两分片集群，某个表有 100 个chunk , 每一个分片分别有 47 和 53 个chunk 。那么此时 balance 认为是均衡的，不会发生迁移。

int threshold = 8;
if (balancedLastTime || distribution.totalChunks() < 20) threshold = 2;
else if (distribution.totalChunks() < 80) threshold = 4;

4.0 版本，chunks 数量差距大于 2 的时候就会发生迁移。一样的上述例子中，每一个分片分别有 47 和 53 个 chunk时， balance 认为是不均衡的，会发生迁移。

const size_t kDefaultImbalanceThreshold = 2; const size_t kAggressiveImbalanceThreshold = 1;
const size_t imbalanceThreshold = (shouldAggressivelyBalance || distribution.totalChunks()
< 20)
? kAggressiveImbalanceThreshold: kDefaultImbalanceThreshold;
// 这里虽然有个 1 ，可是实际差距为 1 的时候不会发生迁移，由于判断迁移时，还有一个指标：平均每一个分片的最大 ch
unks 数量，只有当 chunks 数量大于这个值的时候才会发生迁移。
const size_t idealNumberOfChunksPerShardForTag = (totalNumberOfChunksWithTag / totalNumberOfShardsWithTag) + (totalNumberOfChunksWithTag % totalNumberOfShardsWithTag ? 1 : 0);

关于此阈值，官方文档也有介绍:

To minimize the impact of balancing on the cluster, the balancer only begins balancing after the distribution of chunks for a sharded collection has reached certain thresholds. The thresholds apply to the difference in number of chunks between the shard with the most chunks for the collection and the shard with the fewest chunks for that collection. The balancer has the following thresholds:

The balancer stops running on the target collection when the difference between the number of chunks on any two shards for that collection is less than two, or a chunk migration fails.

可是从代码上，从3.4 版本开始，此阈值的逻辑就已经变化了，可是文档并无更新。

moveChunk

moveChunk 是一个比较复杂的动做, 大体过程以下：

目的分片，首先要删除要移动的 chunk 的数据。因此会有一个删除任务。

能够在 config.settings 设置 _secondaryThrottle 和 waitForDelete 设置 moveChunk 过程当中 插入数据和删除数据的 write concern

• _secondaryThrottle: true 表示 balancer 插入数据时，至少等待一个 secondary 节点回复；false 表示不等待写到 secondary 节点； 也能够直接设置为 write concern ，则迁移时使用这个 write concern . 3.2 版本默认 true, 3.4 开始版本默认 false；

• waitForDelete: 迁移一个 chunk 数据之后，是否同步等待数据删除完毕；默认为 false , 由一个单独的线程异步删除孤儿数据。

设置方式以下：

use config db.settings.update(
{ "_id" : "balancer" },
{ $set : { "_secondaryThrottle" : { "w": "majority" } ,"_waitForDelete" : true } },
{ upsert : true }
)

3.2 版本 _secondaryThrottle 默认 true, 3.4 开始版本默认 false，因此 3 .2 版本和4.0 版本 moveChunk 迁移数据时，4.0版本会更快完成，迁移中 目的分片的每秒 insert 量级也会更多，对 CPU 负载也会有些许的影响。

另外，3.4.18/3.6.10/4.0.5 及以后版本，还有如下参数 (Parameter) 调整插入数据的速度：

• migrateCloneInsertionBatchDelayMS: 迁移数据时，每次插入的间隔，默认 0 不等待。

• migrateCloneInsertionBatchSize: 迁移数据时，每次插入的数量，默认为 0 无限制。

设置方式以下：

db.adminCommand({setParameter:1,migrateCloneInsertionBatchDelayMS:0})
db.adminCommand({setParameter:1,migrateCloneInsertionBatchSize:0})

异步删除数据线程

3.2 和 4.0 版本的异步删除线程具体实现略有不一样，可是，根本过程仍是一致的，用一个队列保存须要删除的 range, 循环的取队列的数据删除数据。因此异步删除数据线程是按照 chunk 进入队列的顺序，逐个删除。总入口：

3.2 版本 db/range_deleter.cpp 线程入口 RangeDeleter::doWork()
4.0 版本 db/s/metadata_manager.cpp scheduleCleanup 时会有一个惟一的线程执行清理任务

4.0 版本在删除数据时，按批删除数据，每次删除数量计算方式以下：

maxToDelete = rangeDeleterBatchSize.load();
if (maxToDelete <= 0) {
maxToDelete = std::max(int(internalQueryExecYieldIterations.load()), 1); // 128
}

有较多的参数能够灵活的控制删除速度，默认状况下，900s 之后开始清理 chunks 的数据，每次清理 128 个文档，每隔 20ms 删除一次。具体经过如下参数设置：

• rangeDeleterBatchDelayMS: 删除每一个 chunk 数据的时候分批次删除，每批之间间隔的时间，单位 ms，默认 20ms；

• internalQueryExecYieldIterations: 默认为 128；

• rangeDeleterBatchSize：每次删除数据的数量，默认即为0；为0时 ，则每次删除的数量为max(internalQueryExecYieldIterations，1)，

• orphanCleanupDelaySecs: moveChunk 之后延迟删除数据的时间，单位 s ，默认 900 s

总结

• moveChunk 可能对系统的负载产生影响，主要是删除数据阶段的影响，通常迁移中的插入数据影响较小；

• 3.4 及以后的版本存在 balancer 迁移阈值较低的问题，可能会更频繁的产生 moveChunk；

• 文档数据多而小的表，并且是 hashed 分片，本应预分配必定的 chunk 之后永久关闭表的 balancer。开启balancer 时，3.2 版本由于均衡阈值较大，较少发生 moveChunk 迁移数据，因此负载较低； 4.0 版本均衡阈值很小，更容易发生迁移，频繁的迁移以后删除数据致使负载较高。

做者：李鹏冲

网易游戏高级运维工程师，MongoDB和MySQL数据库爱好者，目前专一于SAAS平台的开发与运维工做。

感谢MongoDB官方，锦木信息和Tapdata对活动的大力支持！