DDS数据库均衡慢问题
【摘要】 用户在扩容添加一个shard节点后,balance线程检测到新的shard节点后,开始执行均衡策略,通过执行movechunk命令将其他shard上的一些chunk迁移到新的shard上,进行负载均衡,但是用户发现,执行movechunk的速度特别慢,一个chunk的迁移需要5分钟左右。
经过对movechunk命令的分析,简单讲,该过程相当于把源shard上制定chunk的...
用户在扩容添加一个shard节点后,balance线程检测到新的shard节点后,开始执行均衡策略,通过执行movechunk命令将其他shard上的一些chunk迁移到新的shard上,进行负载均衡,但是用户发现,执行movechunk的速度特别慢,一个chunk的迁移需要5分钟左右。
经过对movechunk命令的分析,简单讲,该过程相当于把源shard上制定chunk的数据插入到新的shard下,影响插入过程的一般有索引,以及其他插入操作;
通过分析用户表的索引和业务,发现用户在某个表上有很多索引;同时,在balance时业务是不中断的,因此我们模拟了类似的业务模型,验证发现
1.索引对movechunk命令执行速度有很大的影响,一般一个表上创建有5个以上索引,就会明显影响movechunk的速度;
2.业务的读写也对movechunk命令有影响,如果chunk上有游标,则movechunk命令会等待游标结束才开始执行,但是这个影响不是很明显;
分析了以上原因后,根据用户的业务,对用户的索引进行了优化,删除了不必要的索引
用户在均衡完成后发现,shard的磁盘使用率并没有降低。
这是因为mongodb默认,不会把已申请到的磁盘空间返还给操作系统,因此磁盘的使用率没有降低,但是mongodb会重新利用磁盘里的空间,也就是说,继续插入数据时,mongodb首先使用它自己已经申请的磁盘,因此这个问题影响不大,不会造成磁盘空间浪费;
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)