一次服务器IO占用率高的定位分析

一次服务器IO占用率高的定位分析

情况:外出度假，听服务平台群里朋友的意见，反馈了一个难题。在制造业数据库查询中导入一些数据信息时，手机客户端的浏览请求会超时。基本准确定位是因为网络服务器磁盘占用IO过高，导入数据信息时IO会飙升到100%。导致很多数据库查询的查询 *** 作缓慢导致手机客户端超时响应请求，所以无奈暂时停止了导入数据信息的脚本制作，也耽误了这些数据信息的制造检验。所以第二天回到公司，我就把钱投入到定位跟踪这个问题上。

自然环境描述:

计算机 *** 作系统

系统文件

数据库查询

一开始大家的数据库都是查询一个比较大的表的数据信息，但是只有几块300w，对于MySQL来说还是可以正常解决的。而且手机客户端的并发只有1K，数据库查询的TPS不超过100。我依次应用了top，iostat检测到的IO利用率早已达到极限。最后利用特殊工具iotop找到了一个吃IO的罪犯jbd2。

概述
日志记录块设备(JBD)为文件系统日志记录提供了一个独立于文件系统的接口。已知ext3、ext4和OCFS2使用JBD。从linux2.6.28和ext4开始的OCFS2使用了一个名为JBD2的JBD的分支。

理解它的关键作用是将日志写入系统文件。那么一定是因为实际 *** 作系统文件过于频繁，导致IO工作压力过大。是流程问题，系统软件问题还是？

目前我的网络服务器上只有一个IO需要大量的实际 *** 作，那就是MySQL数据库查询。会不会是他造成的？带着这个疑问，我用google搜索mysql和jbd2作为关键词，得到了这样一个案例线索:sync_binlog，innodb_flush_log_at_trx_commit，这是两个mysql的附件。突然，我好像想到了什么，于是我翻到《高性能MySQL》这本书的第十章——副本的章节目录(从上面对自然环境的描述可以看出我应用了MySQL的主副本)，找到了sync_binlog的指示。

innodb_flush_log_at_trx_commit呢？

如果innodb_flush_log_at_trx_commit设置为0，则日志缓冲区将每秒加载一次到日志文件中，实际的刷新日志文件的 *** 作将单独进行。这样在事务管理提交的情况下，不容易主动开始加载磁盘的实际 *** 作。

如果innodb_flush_log_at_trx_commit设置为1，MySQL会在每次提交事务管理时，将日志缓冲区的数据信息加载到日志文件中，并刷新出磁盘。

如果innodb_flush_log_at_trx_commit设置为2，MySQL会在每次提交事务管理时将日志缓冲区的数据信息加载到日志文件中。但是实际的冲洗(刷出磁盘) *** 作就不单独进行了。这样MySQL就会每秒执行一次flush的实际 *** 作。

由于我们业务流程数据信息的特点，数据信息的可信度没有金融行业和订单管理系统高。在测量下，我们设置sync_binlog每500次更新一次磁盘，并设置innodb_flush_log_at_trx_commit为2，然后使用iotop等专用工具查询系统软件的IO状态，大大降低了。好了，这个持刀杀死木卫一的罪犯终于被找到并解决了。

续:整个解决这个难题的过程有两集。

一位领导干部叫了几个人对这个难题进行专家会诊。他们有的猜测是服务器空不足，有的猜测是脚本难做，有的猜测是数据库查询本身效率高……我非常非常抵制不经过特征监督和数据分析就用空猜测难题的做法。希望给所有靠故弄玄虚和精准定位的人提个建议。请不要随便评判你不知道的难题。因为别人不轻易把你当大神，总是对你充耳不闻。

找到jbd2的难题后，看到一些社区论坛的解决方案，说是因为linux核心的bug，可以选择在线升级核心或者更换核心设备，可能是对的，但是即使能处理这个问题，成本也是很高的。希望大家在遇到难题的时候，可以进一步分析利用互联网资源和整合自己的情况，然后选择选择哪些解决方案，适合自己的才是最好的。

参考资料:
http://UNIX.stackexchange.com/questions/86875/determining-specific-file-responsible-for-high-I-o
http://serverfaultquestions/363355/io-wait-cause-so-much-down-ext4-jdb2-at-99-io-during-MySQL-commit
http://blog.itpub.net/2265