【移动应用开发技术】如何分析磁盘IO高的问题排查过程

【移动应用开发技术】如何分析磁盘IO高的问题排查过程

这期内容当中在下将会给大家带来有关如何分析磁盘IO高的问题排查过程，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。我们服务器搭建了cacti进行监控，一次通过查看磁盘IO图像的时候，发现每天凌晨3：20-3：35的时候磁盘IO一下飙的很高，然后想知道到底是哪个进程占用那么高的IO，下面是解决方法：写个检测脚本check_io_process.sh,当磁盘IO占用高的时候进行磁盘IO读写进程次数的检测:#!/bin/bash#Date:2013/8/20#Author:zhangkai#Description:ThisscriptisusedtocheckIOhigherprocess.#History:iostat_log=/data/logs/iostat/iostat.logdmesg_log=/data/logs/iostat/dmesg.logdstat_log=/data/logs/iostat/dstat.logif[!-d/data/logs/iostat];thenmkdir-p/data/logs/iostatfiadd(){str=$@sum=`echo${str///+}|bc-l`}iostat-x15>$iostat_logidle_percent=`cat$iostat_log|awk'BEGIN{flag=0}{if(flag==1){print$12;flag=0;}if(index($0,"%util"))

{flag=1;}}'`add$idle_percent#求5次查询IO占用率的平均值avg=`echo$sum/5|bc`if[[$avg-ge70]];thenecho1>/proc/sys/vm/block_dumpecho"">>$dmesg_logecho`date"+%Y-%m-%d%H:%M:%S"`>>$dmesg_logpython/data/dmesg_io.py>>$dmesg_logecho"">>$dstat_logecho`date"+%Y-%m-%d%H:%M:%S"`>>$dstat_logdstat-d--top-bio110>>$dstat_logecho0>/proc/sys/vm/block_dump

fi其中该shell脚本调用了检测磁盘IO读写进程次数的python脚本,下面是dmesg_io.py的代码：#!/usr/bin/python#Monitoringper-processdiskI/Oactivity#writtenbyimportsys,os,time,signal,reclassDiskIO:def__init__(self,pname=None,pid=None,reads=0,writes=0):self.pname=pnameself.pid=pidself.reads=0self.writes=0defmain():argc=len(sys.argv)ifargc!=1:print"usage:./iotop"sys.exit(0)ifos.getuid()!=0:print"mustberunasroot"sys.exit(0)signal.signal(signal.SIGINT,signal_handler)os.system('echo1>/proc/sys/vm/block_dump')print"TASK

PID

READ

WRITE"#

whileTrue:os.system('dmesg-c>/tmp/diskio.log')l=[]f=open('/tmp/diskio.log','r')line=f.readline()whileline:m=re.match(\'^(\S+)\((\d+)\):(READ|WRITE)block(\d+)on(\S+)',line)ifm!=None:ifnotl:l.append(DiskIO(m.group(1),m.group(2)))line=f.readline()continuefound=Falseforiteminl:ifitem.pid==m.group(2):found=Trueifm.group(3)=="READ":item.reads=item.reads+1elifm.group(3)=="WRITE":item.writes=item.writes+1ifnotfound:l.append(DiskIO(m.group(1),m.group(2)))line=f.readline()time.sleep(1)foriteminl:print"%-10ssdd"%\(item.pname,item.pid,item.reads,item.writes)defsignal_handler(signal,frame):os.system('echo0>/proc/sys/vm/block_dump')sys.exit(0)if__name__=="__main__":main()发现在3：20-3：35的日志如下(仅列出部分)：[root@localhostiostat]#catdmesg.log2013-08-2203:23:06TASK

PID

READ

WRITEupdatedb

18661

2951

0kjournald

804

0

525kjournald

1826

0

5762013-08-2203:24:05TASK

PID

READ

WRITEupdatedb

18661

3007

0kjournald

804

0

238kjournald

1826

0

112flush-8:0

11687

0

182013-08-2203:25:05TASK

PID

READ

WRITEupdatedb

18661

2689

0kjournald

804

0

229kjournald

1826

0

44说明是updatedb这进程惹的祸，google查之，这个是由[cron]自动运行的更新系统数据的脚本。其作用是为你系统里面的文件建立索引，以便于locate和whereis等查询命令的能够快速执行而我们服务器/data/目录每天会产生大量的小文件，导致建立索引的时候占用很高的磁盘IO服务器每天定时对硬盘上的文件进行索引，简单的说就是建立一个数据库，把所有文件目录信息存放到这个库里面，当使用whereis和locate命令搜索文件时，它直接到这个数据库中读取数据。而不是像find一样在硬盘上找文件。Whereis搜索一个文件几乎只要几秒钟就可以搞定，而find需要花费几分钟或者更长时间。updatedb.Conf使搜索的效率提高了很多倍。但是有缺点，它每天都需要索引更新，这会导致IO负载过高，因为不是时时更新，所以会出现搜索到已经删除的文件，搜不出新添加的文件，平时管理中我们很少用到。如果文件数量多而且更新平凡，我们大可把这个功能关闭优化方法：1.停止对/data目录进行