一次另类的由kjournald日志进程引起的磁盘io问题的解决

最近linode的服务器做cacti的监控测试，偶尔发现服务器最近几周的io成几何级增长

而同期的cpu负载却发现无太明显的几何级的增长

好在linode公司对我的服务器没有进行特别处理，只是发了发警告信，但也不能不理呀，否则这io还得无限的增长。

解决问题过程：

看数据的变化似乎就是最近2周才开始恶劣变化，细细回想最近对服务器做过的操作，无非做了以下改动:1是mysql主从复制;2是snmp+cacti，从时间上看mysql的主从配置更加有可能罪魁祸首。

1：由于mysql的主从配置需要写大量的log-bin文件，所以很大可能是因为读写log-bin引起的，所以我关闭主从复制，而且还关闭了log-bin文件的写入

观察结果显示：磁盘io还是呈几何级增长，看来不是mysql的主从复制的问题

 

2：snmpd的问题？虽然时间上不大可能，但我还是尝试把snmpd关闭，并停止cacti的监控，防止rrdtool写入新的图片文件。

 

观察后显示：磁盘IO还是继续增长

 

3：排除了以上2个可能，我有点犹豫了，所以用iotop工具来观察到底是哪个应用程序占用的io比较大，通过程序发现3个程序相对占用io比较大

分别是kjournald；php5-cgi;mysql

我们先来排除后两者，显然最近几个星期，可以说最近200天，服务器都没重启过，我更没有闲情逸致去修改php，nginx和mysql的配置，他们出问题的可能性不大。

那kjournald是什么呢？

EXT3文件系统的日志进程

显然可能有相关的日志文件产生，而且产生的深度还挺大，造成读写困难

果然，空间使用率从以前的5G升到占用8G，显然有重大文件产生

解决：后来的解决我没有耐心做排除法，我把可能的日志文件都进行了处理，至于具体是哪个可能得等到下次再来做精确判断了

1: /var/spool/mqueue-client 下的文件,这个只需要在cron的计划中把所有输出的文字到用> /dev/null 2>&1 处理掉  删除之前,磁盘占用1G左右,处理之后一天都没产生一个文件

2:/var/log/下的 mail.info和mail.log文件，可能不断有信息通过邮件的方式发送到root@localhost,所以这2个文件非常大，显然读写肯定也是成问题的，处理前2个文件占用2.4G，暂时找不到防止增长的办法，先删除之

3：/var/cache/eaccelerator的文件，我估计这个不是罪魁祸首，不过昨天处理的时候，也一并都清空了，因为当时也占用了将近800M的文件，eaccelerator是什么我不用介绍吧。

 

好了，处理完这个，重启系统，运行半天，哈哈，io下来的，看来问题就出在刚才的那几个问题之中，以后如果还有类似情况，我再做精确判断

看看降下来的io图对比，非常明显哦

同期的cpu负载变化情况

cpu负载有点小波动，我估计是清理php缓存，重新生成的缘故。

 

好了，至此linode的io问题解决，以后要特别注意日志文件的产生对磁盘io的影响问题。希望这篇文章能给大家解决问题的思路