找出mongodb中未被检测出的Jumbo块
2022-04-18 22:45 abce 阅读(156) 评论(0) 编辑 收藏 举报最近在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块,并生成相关命令:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | 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进行调用:
1 | mongos> allChunkInfo( "db.test_col" ) |
会生成执行块分裂需要的命令:
1 2 3 4 5 6 7 8 9 10 11 | 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版本,最好不时查看你的块统计信息以避免一些令人讨厌的意外。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· .NET10 - 预览版1新功能体验(一)
2020-04-18 MySQL没有选对正确的索引怎么办
2020-04-18 OceanBase的产品简介
2017-04-18 12C -- ORA-65048 ORA-65048
2017-04-18 12C -- 创建RMAN备份用户
2016-04-18 DG - 将physical standby置于read-only模式
2016-04-18 set ver on/off