资讯专栏INFORMATION COLUMN

MGR性能抖动问题分析

IT那活儿 / 3634人阅读
MGR性能抖动问题分析

点击上方“IT那活儿”,关注后了解更多内容,不管IT什么活儿,干就完了!!!





问题现象



在对MGR 5.7.30版本进行性能压力测试的时候出现周期性的性能骤降。
如上图所示,会从TPS从1400降低为0。





问题复现



1. 使用sysbench 开启128线程并行对MGR集群进行插入:
/usr/local/sysbench/bin/sysbench --test=oltp.lua --oltp-table-size=100000 --oltp_tables_count=10 --mysql-db=test --
mysql-user=root --mysql-password=X --socket=/var/lib/mysql/mysql.sock --db-driver=mysql --rand-init=on prepare  

/usr/local/sysbench/bin/sysbench --test=insert.lua --num_threads=128 --max-time=720  --max-requests=0   --report-
interval=1   --oltp-table-size=1000000 --mysql-db=test --
mysql-user=root --oltp-tables-count=10 --mysql-password=X  run
2. 以下为压测结果截图:





问题定位



1. 根据出现writes为0的时间间隔来判断在60秒左右。
根据MGR的运行机制,每60秒会对内存当中的WriteSet进行清理,而清理之前会加锁来阻塞新事务生成的WrieSet进入内存区,加锁之后对内存当中所有WriteSet进行遍历,判断哪些WriteSet可以清理。如果内存当中WriteSet的数量很多,那加锁的时间也就会越长。
2. 可以通过以下命令查看内存当中WriteSet的数量:
select COUNT_TRANSACTIONS_ROWS_VALIDATING from replication_group_member_statsG
3. 要验证是否因为WriteSet清理导致事务阻塞所以进行如下测试:
使用大并发的插入,使得WriteSet的数量急剧增加,然后停止并发插入,观察WriteSet清理情况。

1)通过sysbench将WriteSet增加:

上图:可以看到COUNT_TRANSACTIONS_ROWS_VALIDATING的值已经有4450518了。这时候sysbench的写入也出现为0的情况,说明WriteSet已经足够多。

2)停止sysbench观察WriteSet的清理:

从上图可以看到,18:22:08和18:23:08的时候开始进行WriteSet的清理,时间间隔刚好60秒。从WriteSet数值的变化来看由12324198降低到12157800耗时14秒。
可以说明WriteSet每隔60秒清理一次,WriteSet量到达12324198的时候清理速度为14秒。

3)验证清理的时候事务是否会被阻塞:

为了验证是否阻塞插入,写了个循环插入脚本,每隔一秒进行插入,并打印插入的时间。
通过上图可以证明,19:00:09 WriteSet开始明显下降,19:00:12 WriteSet开始上升。再对比左边的插入脚本,19:00:09开始插入直到19:00:12才开始插入下一条。说明在清理WriteSet的时候会阻塞事务。





优化建议



1. 限流

上面两张图的对比,WriteSet达到1200万的时候清理一次14秒,而300万的时候清理一次2秒
可以使用如下命令监控WriteSet的数量,如果非常的大,对MGR集群进行限流。
select COUNT_TRANSACTIONS_ROWS_VALIDATING from replication_group_member_statsG
限流参数:
  • group_replication_flow_control_mode

  • group_replication_flow_control_applier_threshold

  • group_replication_flow_control_certifier_threshold

2. 减少唯一索引数量

经过测试,唯一索引数量越多,单个事务产生的WriteSet越多。
通过对比发现,多一个唯一索引,会多生成2个WriteSet。



本文作者:许智发

本文来源:IT那活儿(上海新炬王翦团队)

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129608.html

相关文章

  • 深度分析 | MGR相同GTID产生不同transaction故障分析

    摘要:对于该故障的分析,我们要从主从实例相同,但是事务不同的原因入手,该问题猜测与相关,我们针对同步事务的时序做如下分析。接受者被动接收提议者的提议,并记录和反馈,或学习达成共识的提议。节点将的提案信息发送至组内,仍收到了大多数成员返回。 本文是由爱可生运维团队出品的「MySQL专栏」系列文章,内容来自于运维团队一线实战经验,涵盖MySQL各种特性的实践,优化案例,数据库架构,HA,监控等...

    wuaiqiu 评论0 收藏0
  • 如何利用Docker构建基于DevOps的全自动CI

    摘要:三私有代码库阿里云使用引言使用肯定离不开和代码的集成。本着代码可靠性,服务器稳定性,功能扩展性综合对比,我们选择使用阿里云的库。 来自用户的DevOps实践分享,分享从开发代码到生产环境部署的一条龙操作的实践及经验, 包含工具技术的选型及考量、私有代码库与私有镜像库的应用等。 (一)容器服务的Rancher选型 1、为什么说是下一代核心技术 从互联网的多次变革说起,早期的C/S架构,到...

    stormzhang 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<