mysql优化之使用iotop+pt-ioprofile定位具体top io文件

今天，将一个环境切换成行情优化后的版本后，发现io等待还是挺高，这还是第一次出现的。其他很多套环境都没有这个问题了，故iotop看了下，基本可以确定为是mysql进程的问题，如下：



但是iotop只能看到进程级别，对于rdbms而言，通常力度并不够，此时需要进一步使用其他工具比如io-profile（io-profile需要安装percona-toolkit，具体可搜索网上，比如http://www.cnblogs.com/zping/p/5678652.html），可以进一步attach到具体的进程，然后定位到具体的文件，如下：

[root@iZbp112kwadw1qt8emked5Z local]# pt-ioprofile  --profile-pid=26256 --cell=sizes --run-time=30
Fri Feb 17 10:57:45 CST 2017
Tracing process ID 26256
total      pread       read     pwrite      write      fsync       open      close      lseek      fcntl filename
64987456040    9890596      48180          0          0          0          0          0 64977517264          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/mysql/proc.MYD
17101824          0          0   17101824          0          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/ib_logfile0
8159232          0          0    8159232          0          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_act/tb_act_stock_quotation_tmp.ibd
5329976        137        591    5308416          0          0          0          0      20832          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_sys/tb_sys_stock_info_tmp.ibd
1474560          0          0    1474560          0          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/ibdata1
632856       3400      14800     114688          0          0          0          0     499968          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_sys/tb_sys_stock_info_tmp.frm
564372       4150      18590          0          0          0          0          0     541632          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_act/tb_act_stock_quotation_tmp.frm
132508          0          0          0     132508          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/mysql-bin.000056
15028          0          0          0      15028          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/iZbp112kwadw1qt8emked5Z.err
9189          0          0          0       9189          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/iZbp112kwadw1qt8emked5Z-slow.log
2742          0          0          0          0          0          0          0       2742          0 /tmp/ibpJOVg5
0          0          0          0          0          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_sys/tb_sys_stock_info.ibd
0          0          0          0          0          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_rsk/tb_rsk_compliancecalcservice.ibd
0          0          0          0          0          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_act/tb_act_stock_quotation.ibd
[root@iZbp112kwadw1qt8emked5Z local]#

pread/read/pwrite/write的区别如下：

内核文件I/O－＞标准库I/O－＞高级I/O－＞IPC

关于read/pread和write/pwrite的解释，可以参考http://www.cnblogs.com/brill/p/3226439.html，但是关于引入pread/pwrite的背景原因，应该来说现行网上的解释都不是很好，只有帖子http://tieba.baidu.com/p/2850517299的一个答复者精确的说明了这个问题，如下：

首先pread、pwrite提出的背景是早期的UNIX没有正确地实现O_APPEND，因而引入一对原子操作，来解决append过程中的“脏写”问题。解决方法就是靠第四个参数来给每个进程（线程）分配各自的读写空间，避免它们的读写空间相互覆盖。前提是程序员清楚地知道每个线程需要多大的读写空间。
其次，如果有循环读写的需求，也需要修改第四个参数，从而改变起始位置。
总之，pread、pwrite是一对很实用的随机读写接口。

很多框架或者类库发展到成熟版本后，很多特性或者接口为何以当前这样的方式实现或者提供，有时候真得知道或者了解当时的技术限制、业务场景，才能领会，否则很可能就是觉得很多今天看起来很普通的特性、为什么框架作者绕了一个大圈子来实现。

在我们的系统中，因为大量使用了存储过程，所以导致proc.MYD的lseek奇高。而tb_act_stock_quotation_tmp.ibd和tb_sys_stock_info_tmp.ibd则是load infile local到innodb文件所致。将这两个表的引擎改成memory后，io等待就降低到1%以下，而且从io-profile中消失了，如下：

[root@iZbp112kwadw1qt8emked5Z logs]# pt-ioprofile  --profile-pid=26256 --cell=sizes --run-time=30
Fri Feb 17 11:25:23 CST 2017
Tracing process ID 26256
total      pread       read     pwrite      write      fsync       open      close      lseek filename
68397517302    9658786      49780          0          0          0          0          0 68387808736 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/mysql/proc.MYD
4276736          0          0    4276736          0          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/ib_logfile2
1991058      13836      60678          0          0          0          0          0    1916544 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_sys/tb_sys_stock_info_tmp.frm
138261          0          0          0     138261          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/mysql-bin.000056
86948        660       2960          0          0          0          0          0      83328 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/db_act/tb_act_stock_quotation_tmp.frm
16041          0          0          0      16041          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/iZbp112kwadw1qt8emked5Z.err
2742          0          0          0          0          0          0          0       2742 /tmp/ibpJOVg5
460          0          0          0        460          0          0          0          0 /usr/local/Percona-Server-5.6.31-rel77.0-Linux.x86_64.ssl101/data/iZbp112kwadw1qt8emked5Z-slow.log

但是，这个时候绝大部分的读写都在mysql/proc.MYD，该文件保存是mysql存储过程的表所存储的文件。

因为proc.MYD是MyIsam表，它只能cache index，mysql层面无法缓存data，要解决这个问题，就得看看有没有方法在linux层面将其缓存起来。