MySQL-如何定位导致mysql服务器io压力大的进程？

Question

我这里就不贴日志了，因为太多了，我也不知道贴那块比较合适，我就想知道各位大侠在处理这种问题上一些经验技巧就足以了，可以从不同方面帮忙分析一下，我这里就谢过了。。。

Answer 1

我个人感觉MySQL的IO大不应该看是哪个进程造成的，造成MySQL IO大的瓶颈还是在MySQL存储数据上，最大的原因是某条SQL造成了IO瓶颈。在MySQL里可以通过"show processlists"命令查看一下有哪些命令是被阻塞，处于等待状态。还应该为MySQL开启慢查询日志。打蛇打七寸，要找到是什么原因造成MySQL IO压力大的原因，是SQL？ 并发大？ 还是数据库设计不合理？等等，只有找到了问题所在才能对症下药。这是我的个人观点。

Answer 2

你还可以在数据库中看看哪个应用连接最多，查看慢查询日志，再看看是否由不优化的语句、索引不合理的情况；再看看哪个连接数据库的页面执行时间比较长。

Answer 3

1.你可以在root账户下，运行iostat,vmstat,查询看看。
分析磁盘IO，要用到两个命令：iostat 和 sar。
iostat -d -x 10 3
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
主要字段含义如下：
r/s 每秒读操作数。
w/s 每秒写操作数。
rsec/s 每秒从设备读取的扇区数量。
wsec/s 每秒向设备写入的扇区数量。
avgrq-sz I/O 请求的平均扇区数。
avgqu-sz I/O 请求的平均队列长度。
await I/O 请求的平均等待时间，单位为毫秒。
svctm I/O 请求的平均服务时间，单位为毫秒。
%util 处理 I/O 请求所占用的时间的百分比，即设备利用率。

#sar -pd 10 3
输出的主要字段含义如下：
DEV 正在监视的块设备
tps 每秒钟物理设备的 I/O 传输总量
rd_sec/s 每秒从设备读取的扇区数量
wr_sec/s 每秒向设备写入的扇区数量
avgrq-sz I/O 请求的平均扇区数
avgqu-sz I/O 请求的平均队列长度
await I/O 请求的平均等待时间，单位为毫秒
svctm I/O 请求的平均服务时间，单位为毫秒
%util I/O 请求所占用的时间的百分比，即设备利用率
Unix/Linux 系统磁盘 I/O 性能监控自动化脚本示例
2.用iotop可以看到是哪些进程IO占用高，不过需要2.6.20以上的kernel

Answer 4

建议你在上线的前尽量做一下压力测试，负责上线后会很头疼的，造成io压力的原因有挺多的，光看日志的话需要你有很厚实的经验去分析里边的细节，这里我提几点后面大家可能会遇到此问题的一些防范措施：
要注意的事项是：
1. 对iops的限制是针对每个线程的，总的限制是 限制*线程数
2. 在thinktime_blocks个io开始前先等待thinktime(其中thinktime_spin用于消耗cpu, 剩余时间用于sleep)
3. 每个io需要花费时间。这个时间随着设备的不同差别很大，最好的方法是测试。用一个线程测试，然后用strace查看。
4. 最后推荐一个模拟测试工具，fio是个非常好用的io压力模拟工具，功能非常齐全， 有兴趣的同学参看 这里。
这里我用fio模拟我们线上mysql服务器的压力来为厂家送来的pci-ssd卡做压力测试，也许有的同学有用。