找出mongodb中未被检测出的Jumbo块

最近在MongoDB集群中遇到了一个有趣的性能问题案例。通过挖掘日志，发现问题与需要很长时间进行块移动有关。

我们知道，默认的最大块大小是64MB。因此，在当今使用的大多数硬件中，这些迁移应该非常快。在这样的情况，居然有几个超出该限制的chunk被移动了，为什么有这种情况发生呢？这些块是否已经被标记为Jumbo chunk?

块移动(chunk moves)

块中的documents的数量如果大于块的大小(默认是64MB)除以document的平均大小的值的1.3倍。就不会移动块。

如果一个集合中document的平均大小是2KB，一个chunk中超过42597(65536/2*1.3)个document的时候，该块就不会被balance。这对集合中document大小不统一的场景就会是个问题，以为评估可能不准。

如果chunk的大小超过了最大值，就会被标记为Jumbo，这表示balancer不会移动该块。

最后，我们要知道的是，移动块的过程需要施加一个元数据锁，在移动过程中就会阻塞写操作。

autoSplitter行为

在mongodb4.2之前，运行在mongos router上的autoSplitter进程负责保证块的大小不会超过最大值。router进程跟踪统计信息，这些统计信息用于决定块分裂。

在生产环境中的一个问题是，通常有很多这种mongos router进程，单个mongos router只是知道某个块上发生的部分信息。

如果多个mongos router进程修改相同块上的数据，块的大小会超过最大值而不被觉察到。

频繁重启mongos进程也会导致该问题，这会导致用于决定块分裂的统计信息被重置。

正因为这些原因，从mongodb 4.2开始，autoSplitter进程被修改成运行在每个分片复制集的主成员上。

找出未被检测出的Jumbo块

使用以下脚本找出未被检测到的Jumbo块，并生成相关命令：

var allChunkInfo = function(ns){
    var chunks = db.getSiblingDB("config").chunks.find({"ns" : ns}).sort({min:1}).noCursorTimeout(); //this will return all chunks for the ns ordered by min
    var totalChunks = 0;
    var totalJumbo = 0;
    var totalSize = 0;
    var totalEmpty = 0;
 
    chunks.forEach( 
        function printChunkInfo(chunk) { 
          var db1 = db.getSiblingDB(chunk.ns.split(".")[0]) // get the database we will be running the command against later
          var key = db.getSiblingDB("config").collections.findOne({_id:chunk.ns}).key; // will need this for the dataSize call
         
          // dataSize returns the info we need on the data, but using the estimate option to use counts is less intensive
          var dataSizeResult = db1.runCommand({datasize:chunk.ns, keyPattern:key, min:chunk.min, max:chunk.max, estimate:false});
         
          if(dataSizeResult.size > 67108864) {
            totalJumbo++;
            print('sh.splitFind("' + chunk.ns.toString() + '", ' + JSON.stringify(chunk.min) + ')' + ' // '+  chunk.shard + '    ' + Math.round(dataSizeResult.size/1024/1024) + ' MB    ' + dataSizeResult.numObjects );
          }
          totalSize += dataSizeResult.size;
          totalChunks++;
          
          if (dataSizeResult.size == 0) { totalEmpty++ }; //count empty chunks for summary
          }
    )
    print("***********Summary Chunk Information***********");
    print("Total Chunks: "+totalChunks);
    print("Total Jumbo Chunks: "+totalJumbo);
    print("Average Chunk Size (Mbytes): "+(totalSize/totalChunks/1024/1024));
    print("Empty Chunks: "+totalEmpty);
    print("Average Chunk Size (non-empty): "+(totalSize/(totalChunks-totalEmpty)/1024/1024));
}

脚本必须通过mongos router进行调用：

mongos> allChunkInfo("db.test_col")

　　

会生成执行块分裂需要的命令：

sh.splitFind("db.test_col", {"_id":"jhxT2neuI5fB4o4KBIASK1"}) // shard-1    222 MB    7970
sh.splitFind("db.test_col", {"_id":"zrAESqSZjnpnMI23oh5JZD"}) // shard-2    226 MB    7988
sh.splitFind("db.test_col", {"_id":"SgkCkfSDrY789e9nD4crk9"}) // shard-1    218 MB    7986
sh.splitFind("db.test_col", {"_id":"X5MKEH4j32OhmAhY7LGPMm"}) // shard-1    238 MB    8338
...
***********Summary Chunk Information***********
Total Chunks: 5047
Total Jumbo Chunks: 120
Average Chunk Size (Mbytes): 19.29779934868946
Empty Chunks: 1107
Average Chunk Size (non-empty): 24.719795257064895

dataSize的estimate: true参数会导致使用documents的平均大小来执行estimate。如果document的大小不一致，会导致估算的值不准，但是运行速度会快一点，且资源耗费低一点。如果你知道document的大小都差不多，可以设置为true。

 

运行生成的脚本，就不会有Jumbo chunk了。在下一次balance窗口，balancer进程就会移动块。

 

为了降低影响，建议在负载低峰期调度balance窗口。

最后

MongoDB 3.6之后，autoSplitter在控制块大小方面应该做得更好。如果仍在运行4.2之前的MongoDB版本，最好不时查看你的块统计信息以避免一些令人讨厌的意外。