某台服务器的IO负载很高（iostat中的util），但是无法快速的定位到IO负载的来源进程和来源文件，查到是mysql导致的，不过不能定位是那个文件最占用IO
zabbix图形：
# top
可以见到zabbix图形有规则性，可能是定时任务导致，top命令可以见到cpu的%wa很高，io在等待写入。
排查系统日志，关掉系统所有定时任务发现问题没有消失，可能是程序定时任务导致？再排查，开发屏蔽当前版本的定时任务，问题还是没有消失。
定位IO负载来源：
一、# iotop
可以见到jbd2进程某时刻占用IO达到99%,导致IO阻塞，mysql连接断掉，用户反映访问出现缓慢。
JDB2导致磁盘io使用率高？
参考网上一篇文章，http://xujpxm.blog.51cto.com/8614409/1674378
http://ju.outofmemory.cn/entry/178162
1、yum update kernel 用yum升级系统内核，重启之后查看是否有效；
2、缓解方法：修改commit值，降低文件系统提交次数或者禁用barrier特性；
建议文件系统参数为：defaults,noatime,nodiratime,barrier=0,data=writeback,commit=60
（可以通过修改fstab表或者remount重新挂载）
3、慎用方法：关闭文件系统日志功能 tune2fs -O "^has_journal" 例如： tune2fs -O "^has_journal" /dev/mapper/VolGroup-lv_home
问题还是没有解决，这次是mysql进程占用IO到99%。
二、pt-ioprofile定位负载来源文件
可以看到占用IO的都是mysql日志文件和表结构文件
可能是mysql日志占用IO或者分配给mysql的内存空间不够？
关掉mysql的二进制文件写入，优化mysql的配置（增大内存，减少IO），问题还是没解决。
三、业务要求先迁移线上数据再进行测试，迁移数据库过程中报错：
这个库的'log_open_gift'表怎么备份都报错
有可能是备份正在达到MySQL超时限制，修改mysql配置。
参考网址：https://ottomatik.groovehq.com/knowledge_base/topics/solving-error-2013-lost-connection-to-mysql-server-during-query-when-dumping-table
net_read_timeout = 120
net_write_timeout = 900
增加max_allowed_packet设置。
max_allowed_packet = 512M
还是备份失败，判断为损坏的表，尝试修复无果，排查最后一步为ssd硬盘存在坏道？
# badblocks -v /dev/vdb1 > badsectors.txt
OK，9个坏道好样的。
记一次个人排查经过，如有不足或不妥，多谢指出~
