MySQL服务器 IO 100%的分析与优化方案

前言

压力测试过程当中，若是由于资源使用瓶颈等问题引起最直接性能问题是业务交易响应时间偏大，TPS逐渐下降等。而问题定位分析一般状况下，最优先排查的是监控服务器资源利用率，例如先用TOP 或者nmon等查看CPU、内存使用状况，而后在排查IO问题，例如网络IO、磁盘IO的问题。 若是是磁盘IO问题，通常问题是SQL语法问题、MYSQL参数配置问题、服务器自身硬件瓶颈致使IOPS吞吐率问题。

本文主要给你们介绍的是关于MySQL服务器 IO 100%的分析与优化方案，下面话很少说了，来一块儿看看详细的介绍吧

【问题】

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

写入IOPS很高

【分析过程】

一、经过iotop工具能够看到当前IO消耗最高的mysql线程

二、查看线程49342的堆栈，能够看到正在进行redo log的刷新，对应的是9号文件

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

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

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

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

【优化方案】

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

二、MySQL层面，对于日志类型的系统，若是容许宕机的状况下少许数据丢失，能够将innodb_flush_log_at_trx_commit参数调整为2，

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

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

三、系统层面，更换性能更佳的磁盘

总结

以上就是这篇文章的所有内容了，但愿本文的内容对你们的学习或者工做具备必定的参考学习价值，若是有疑问你们能够留言交流，谢谢你们对脚本之家的支持。

您可能感兴趣的文章:

• Mysql IO 内存方面的优化

文章同步发布： https://www.geek-share.com/detail/2751092551.html