Java自学者论坛

 找回密码
 立即注册

手机号码,快捷登录

恭喜Java自学者论坛(https://www.javazxz.com)已经为数万Java学习者服务超过8年了!积累会员资料超过10000G+
成为本站VIP会员,下载本站10000G+会员资源,会员资料板块,购买链接:点击进入购买VIP会员

JAVA高级面试进阶训练营视频教程

Java架构师系统进阶VIP课程

分布式高可用全栈开发微服务教程Go语言视频零基础入门到精通Java架构师3期(课件+源码)
Java开发全终端实战租房项目视频教程SpringBoot2.X入门到高级使用教程大数据培训第六期全套视频教程深度学习(CNN RNN GAN)算法原理Java亿级流量电商系统视频教程
互联网架构师视频教程年薪50万Spark2.0从入门到精通年薪50万!人工智能学习路线教程年薪50万大数据入门到精通学习路线年薪50万机器学习入门到精通教程
仿小米商城类app和小程序视频教程深度学习数据分析基础到实战最新黑马javaEE2.1就业课程从 0到JVM实战高手教程MySQL入门到精通教程
查看: 729|回复: 0

MongoDB集群负载不均衡问题定位及解决

[复制链接]
  • TA的每日心情
    奋斗
    2024-11-24 15:47
  • 签到天数: 804 天

    [LV.10]以坛为家III

    2053

    主题

    2111

    帖子

    72万

    积分

    管理员

    Rank: 9Rank: 9Rank: 9

    积分
    726782
    发表于 2021-7-20 15:01:48 | 显示全部楼层 |阅读模式

    1、问题描述

    这是一套运行在腾讯云上的MongoDB 3.6版本集群,共5个分片,每片规格是6核16GB。

    在压测的过程中,发现第3个分片的CPU使用率长时间高达96%,其它4个分片的CPU使用率都没有超过10%。

     

    2、思考及分析

    首先,我查看慢日志,发现大量与postbox相关的query,半个小时内出现9000多次,每次请求平均耗时200ms左右,planSummary为IXSCAN,每次扫描和返回的文档数都很少,锁也很少。

    1  planSummary: IXSCAN { serviceUserId: 1, updatedDate: -1, messageType: 1 } keysExamined:0 docsExamined:0 cursorExhausted:1 numYields:0 nreturned:0 reslen:340 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } }

    到此,还不能说明问题,但是既然慢日志里面都是与postbox有关的,那么我就去检查一下这个collection

    以下是db.getCollection('postbox').stats()的输出:

    { 
        "sharded" : true, 
        "capped" : false, 
        "ns" : "postbox.postbox", 
        "count" : 1020.0, 
        "size" : 301694.0, 
        "storageSize" : 163840.0, 
        "totalIndexSize" : 184320.0, 
        "indexSizes" : {
            "_id_" : 69632.0, 
            "expireAtTtlIndex" : 53248.0, 
            "serviceUserIdMsgTypeSearchIdx" : 61440.0
        }, 
        "avgObjSize" : 295.0, 
        "nindexes" : 3.0, 
        "nchunks" : 1.0, 
        "shards" : {
            "cmgo-280eoxk3_2" : {
       ……
       省略
    
    }

    可以看出,整个文档只有294KB,包含一个chunk,只分布在"cmgo-280eoxk3_2"这一个节点。这就可以说明为什么这一个节点的负载高,而其它节点负载很低了。

    通过执行sh.status(),可以看到该collection的分片方式为range:

                    postbox.postbox
                            shard key: { "serviceUserId" : 1 }
                            unique: false
                            balancing: true
                            chunks:
                                    cmgo-280eoxk3_2    1
                            { "serviceUserId" : { "$minKey" : 1 } } -->> { "serviceUserId" : { "$maxKey" : 1 } } on : cmgo-280eoxk3_2 Timestamp(1, 0) 

    所以,这个问题的根本原因是:该collection目前数据非常少,只有一个chunk,只分布在一个节点中,所以压测就导致该节点的负载非常高。

     

    3、解决方法

    查阅官方文档,其中有如下说明:

    If you shard an empty collection using a hashed shard key, MongoDB automatically creates two empty chunks per shard, to cover the entire range of the hashed shard key value across the cluster. 
    You can control how many chunks MongoDB creates with the numInitialChunks parameter to shardCollection or by manually creating chunks on the empty collection using the split command.

    意思是使用hashed分片方式,MongoDB会自动为每个片创建2个空的chunks,你也可以在设置该集合的分片时,使用numInitialChunks参数来指定空chunks的数量。

    通过与研发沟通,结合我们的实际情况评估,认为该collection可以使用hashed分片方式。

    所以,备份该集合的数据,然后使用如下方重新指定分片方式,最后导入数据。

    db.runCommand( { shardCollection: "postbox.userPostIndex", key: {serviceUserId:"hashed"}, numInitialChunks: 3 } )

    哎...今天够累的,签到来了1...
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    QQ|手机版|小黑屋|Java自学者论坛 ( 声明:本站文章及资料整理自互联网,用于Java自学者交流学习使用,对资料版权不负任何法律责任,若有侵权请及时联系客服屏蔽删除 )

    GMT+8, 2024-12-22 19:32 , Processed in 0.112354 second(s), 27 queries .

    Powered by Discuz! X3.4

    Copyright © 2001-2021, Tencent Cloud.

    快速回复 返回顶部 返回列表