集群实例负载不均衡问题排查 本节主要介绍负载不均衡的常见处理方法。 对于集群方式部署的实例,常见Shard间负载不均衡,一般有如下原因:没有做分片,片键选择不正确,不做chunk预置,shard间均衡速度低于数据插入速度等。 排查方法 步骤 1 通过客户端连接数据库。 步骤 2 执行如下命令,查看分片信息。 mongos> sh.status() Sharding Status sharding version: { "id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("60f9d67ad4876dd0fe01af84") } shards: { "id" : "shard1", "host" : "shard1/172.16.51.249:8637,172.16.63.156:8637", "state" : 1 } { "id" : "shard2", "host" : "shard2/172.16.12.98:8637,172.16.53.36:8637", "state" : 1 } active mongoses: "4.0.3" : 2 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: yes Collections with active migrations: test.coll started at Wed Jul 28 2021 11:40:41 GMT+0000 (UTC) Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 300 : Success databases: { "id" : "test", "primary" : "shard2", "partitioned" : true, "version" : { "uuid" : UUID("d612d134a4994428ab21b53e8f866f67"), "lastMod" : 1 } } test.coll shard key: { "id" : "hashed" } unique: false balancing: true chunks: shard1 20 shard2 20 “databases”中列出的所有数据库都是通过enableSharding开放了分片的库。 “test.coll”表示开启分片的namespace信息,其中test为集合所在的库名,coll为开启分片的集合名。 “shard key”表示前面集合的分片键,分片方式“id : hashed”表示通过id进行哈希分片,如果是“id : 1”,则代表通过id的范围进行分片。 “chunks”代表分片的分布情况。 步骤 3 根据步骤2查询出的结果,分析分片信息。 1. 如果业务性能存在瓶颈的数据库和集合,在上述“databases”以及子项中不存在,则说明业务集合没有进行分片。对于集群来说这意味着业务只有一个Shard承载,没有应用DDS的水平扩展能力。 此场景下可以通过如下的命令开启分片,充分发挥实例的水平扩展能力。 mongos> sh.enableSharding(" ") mongos> use admin mongos> db.runCommand({shardcollection:" . ",key:{"keyname": }}) 2. 如果“shardKey”分片片键选择不合理,也会导致负载不均衡。典型场景有业务热点数据分布在某个范围内,而分片的片键选择范围分片的方式,那么可能会出现热点数据所在的chunk对应的Shard负载会明显的高于其他Shard,最终导致整体性能出现瓶颈。 此场景下可以通过重新设计片键的分布方式来达到目标,比如将范围分片修改为哈希分片。 mongos> db.runCommand({shardcollection:" . ",key:{"keyname": }}) 说明 一个集合选择了分片方式,则不能在原集合上随时修改。所在集合在设计阶段需要充分考虑分片方式。 更多关于设置数据分片的内容请参见 3. 如果存在集中大批量的插入数据的场景,数据量超过单shard承载能力的话,可能会出现Balance速度赶不上插入速度,导致主shard存储空间占用率过高。 此场景可以使用sar命令查看服务器网络连接情况,分析每个网卡的传输量和是否达到传输上限。 sar n DEV 1 //1为间隔时间 Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil Average: lo 1926.94 1926.94 25573.92 25573.92 0.00 0.00 0.00 0.00 Average: A10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: A11 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: NIC0 5.17 1.48 0.44 0.92 0.00 0.00 0.00 0.00 Average: NIC1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: A00 8173.06 92420.66 97102.22 133305.09 0.00 0.00 0.00 0.00 Average: A01 11431.37 9373.06 156950.45 494.40 0.00 0.00 0.00 0.00 Average: B30 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: B31 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 说明 “rxkB/s”为每秒接收的kB数。 “txkB/s”为每秒发送的kB数。 检查完后,按“Ctrl+Z”键退出查看。 对于网络过高的情况,建议对MQL语句进行分析,优化思路,降低带宽消耗,提升规格扩大网络吞吐能力。 建议排查业务是否存在分片集合的情况消息中未携带ShardKey的情况,此场景下请求消息会进行广播,增加带宽消耗。 控制客户端并发线程数,降低网络带宽流量。 以上操作无法解决问题时,请及时提升实例规格,高规格节点对应更高网络吞吐能力的虚拟机。