mysql io 100_MySQL服务器 IO 100%的案例分析

【问题】

有台MySQL 5.6.21的数据库实例以写入为主,IO %util接近100%

8a88839fad1c7a3407c7c2b212718a7c.png

写入IOPS很高

637af6beed557321131ce42548a91e0d.png

【分析过程】

1、通过iotop工具可以看到当前IO消耗最高的mysql线程

d47decb813a2b44ff6166301fac235c4.png

2、查看线程49342的堆栈,可以看到正在进行redo log的刷新,对应的是9号文件

d724909889cf72cdee749bca1708acb9.png

3、9号文件对应的是redo log的第一个文件

6abf593cfc3174fe4127e5051335a3f6.png

为什么mysql进程会频繁的刷新redo log文件,要结合redolog的刷盘策略来分析,关键是innodb_flush_log_at_trx_commit参数,

默认是1,最安全,但在写压力大的情况下,也会带来较大的性能影响,每次事务提交时MySQL都会把log buffer的数据写入log file,并且flush(刷到磁盘)中去。

202287a03ce2080f76f71172c3a8b704.png

结合这个集群的写入场景来看,大部分都是小事务的写入,每次事务提交都会触发刷盘动作,这种场景下通过增大innodb_log_buffer_size和innodb_log_file_size的优化效果不明显

5c5d252f2ea3dd2b5ff1d6f5825e7151.png

【优化方案】

1、应用层面,对于写压力大的系统,可以将单条的insert语句优化为小批量的insert语句,这样事务commit的次数减少,redo log刷盘减少,性能理论上会有提升

2、MySQL层面,对于日志类型的系统,如果允许宕机的情况下少量数据丢失,可以将innodb_flush_log_at_trx_commit参数调整为2,

当设置为2时,则在事务提交时只做write操作,只保证写到系统的page cache,因此实例crash不会丢失事务,但宕机则可能丢失事务

在这台服务器上测试,将参数调整为2时,IO的请求从200M/S降到约10M/S压力会减少10倍以上

1b3fe525ef38020f329a4dde1f58096f.png

3、系统层面,更换性能更佳的磁盘

0b1331709591d260c1c78e86d0c51c18.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值