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

By | 2013 年 1 月 5 日

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

medium[1]

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

medium[1]

好在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图对比,非常明显哦

medium[1]

同期的cpu负载变化情况

medium[1]

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

 

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

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据