您的位置:首页 > 运维架构 > Linux

linux wa%过高,iostat查看io状况

2013-04-08 23:19 162 查看
再进行一次压力测试,拿着这份数据,已经绝对性的说明问题了。此时那些大牛把代码改了一下,性能立马就上去了,千兆网络直接成为系统瓶颈。并于Java的控制问题,改用Apache直接编译程序模块调用,完成变为可控,问题瞬间解决!


附上iostat的源码:

http://code.google.com/p/tester-higkoo/source/browse/trunk/Tools/iostat/iostat.c


转自:http://hi.baidu.com/higkoo/blog/item/d4f7f822e7871cf8d6cae25e.html



2.iostat来对linux硬盘IO性能进行了解

以前一直不太会用这个参数。现在认真研究了一下iostat,因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器

  #iostat-x110

  Linux2.6.18-92.el5xen02/03/2009

  avg-cpu:%user%nice%system%iowait%steal%idle

  1.100.004.8239.540.0754.46

  Device:rrqm/swrqm/sr/sw/srsec/swsec/savgrq-szavgqu-szawaitsvctm%util

  sda0.003.500.402.505.6048.0018.480.000.970.970.28

  sdb0.000.000.000.000.000.000.000.000.000.000.00

  sdc0.000.000.000.000.000.000.000.000.000.000.00

  sdd0.000.000.000.000.000.000.000.000.000.000.00

  sde0.000.100.300.202.402.409.600.001.601.600.08

  sdf17.400.50102.000.2012095.205.60118.400.706.812.0921.36

  sdg232.401.90379.700.5076451.2019.20201.134.9413.782.4593.16

  rrqm/s:每秒进行merge的读操作数目。即delta(rmerge)/s

  wrqm/s:每秒进行merge的写操作数目。即delta(wmerge)/s

  r/s:每秒完成的读I/O设备次数。即delta(rio)/s

  w/s:每秒完成的写I/O设备次数。即delta(wio)/s

  rsec/s:每秒读扇区数。即delta(rsect)/s

  wsec/s:每秒写扇区数。即delta(wsect)/s

  rkB/s:每秒读K字节数。是rsect/s的一半,因为每扇区大小为512字节。(需要计算)

  wkB/s:每秒写K字节数。是wsect/s的一半。(需要计算)

  avgrq-sz:平均每次设备I/O操作的数据大小(扇区)。delta(rsect+wsect)/delta(rio+wio)

  avgqu-sz:平均I/O队列长度。即delta(aveq)/s/1000(因为aveq的单位为毫秒)。

  await:平均每次设备I/O操作的等待时间(毫秒)。即delta(ruse+wuse)/delta(rio+wio)

  svctm:平均每次设备I/O操作的服务时间(毫秒)。即delta(use)/delta(rio+wio)

  %util:一秒中有百分之多少的时间用于I/O操作,或者说一秒中有多少时间I/O队列是非空的。即delta(use)/s/1000(因为use的单位为毫秒)

  如果%util接近100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘

  可能存在瓶颈。

  idle小于70%IO压力就较大了,一般读取速度有较多的wait.

  同时可以结合vmstat查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

  另外还可以参考

  svctm一般要小于await(因为同时等待的请求的等待时间被重复计算了),svctm的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多也会间接导致svctm的增加。await的大小一般取决于服务时间(svctm)以及I/O队列的长度和I/O请求的发出模式。如果svctm比较接近await,说明I/O几乎没有等待时间;如果await远大于svctm,说明I/O队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核
elevator算法,优化应用,或者升级CPU。

  队列长度(avgqu-sz)也可作为衡量系统I/O负荷的指标,但由于avgqu-sz是按照单位时间的平均值,所以不能反映瞬间的I/O洪水。

  别人一个不错的例子.(I/O系统vs.超市排队)

  举一个例子,我们在超市排队checkout时,怎么决定该去哪个交款台呢?首当是看排的队人数,5个人总比20人要快吧?除了数人头,我们也常常看看前面人购买的东西多少,如果前面有个采购了一星期食品的大妈,那么可以考虑换个队排了。还有就是收银员的速度了,如果碰上了连钱都点不清楚的新手,那就有的等了。另外,时机也很重要,可能5分钟前还人满为患的收款台,现在已是人去楼空,这时候交款可是很爽啊,当然,前提是那过去的5分钟里所做的事情比排队要有意义(不过我还没发现什么事情比排队还无聊的)。

  I/O系统也和超市排队有很多类似之处:

  r/s+w/s类似于交款人的总数

  平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数

  平均服务时间(svctm)类似于收银员的收款速度

  平均等待时间(await)类似于平均每人的等待时间

  平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少

  I/O操作率(%util)类似于收款台前有人排队的时间比例。

  我们可以根据这些数据分析出I/O请求的模式,以及I/O的速度和响应时间。

  下面是别人写的这个参数输出的分析

  #iostat-x1

  avg-cpu:%user%nice%sys%idle

  16.240.004.3179.44

  Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

  /dev/cciss/c0d0

  0.0044.901.0227.558.16579.594.08289.8020.5722.3578.215.0014.29

  /dev/cciss/c0d0p1

  0.0044.901.0227.558.16579.594.08289.8020.5722.3578.215.0014.29

  /dev/cciss/c0d0p2

  0.000.000.000.000.000.000.000.000.000.000.000.000.00

  上面的iostat输出表明秒有28.57次设备I/O操作:总IO(io)/s=r/s(读)+w/s(写)=1.02+27.55=28.57(次/秒)其中写操作占了主体(w:r=27:1)。

  平均每次设备I/O操作只需要5ms就可以完成,但每个I/O请求却需要等上78ms,为什么?因为发出的I/O请求太多(每秒钟约29个),假设这些请求是同时发出的,那么平均等待时间可以这样计算:

  平均等待时间=单个I/O服务时间*(1+2+…+请求总数-1)/请求总数

  应用到上面的例子:平均等待时间=5ms*(1+2+…+28)/29=70ms,和iostat给出的78ms的平均等待时间很接近。这反过来表明I/O是同时发起的。

  每秒发出的I/O请求很多(约29个),平均队列却不长(只有2个左右),这表明这29个请求的到来并不均匀,大部分时间I/O是空闲的。

  一秒中有14.29%的时间I/O队列中是有请求的,也就是说,85.71%的时间里I/O系统无事可做,所有29个I/O请求都在142毫秒之内处理掉了。

  delta(ruse+wuse)/delta(io)=await=78.21=>delta(ruse+wuse)/s=78.21*delta(io)/s=78.21*28.57=2232.8,表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为2232.8ms/1000ms=2.23,而iostat给出的平均队列长度(avgqu-sz)却为22.35,为什么?!因为iostat中有bug,avgqu-sz值应为2.23,而不是22.35。





3.linuxlsof详解

lsof简介


lsof(listopenfiles)是一个列出当前系统打开文件的工具。在linux环境下,任何事物都以文件的形式存在,通过文件不仅仅可以访问常规数据,还可以访问网络连接和硬件。所以如传输控制协议(TCP)和用户数据报协议(UDP)套接字等,系统在后台都为该应用程序分配了一个文件描述符,无论这个文件的本质如何,该文件描述符为应用程序与基础操作系统之间的交互提供了通用接口。因为应用程序打开文件的描述符列表提供了大量关于这个应用程序本身的信息,因此通过lsof工具能够查看这个列表对系统监测以及排错将是很有帮助的。


lsof使用


lsof输出信息含义


在终端下输入lsof即可显示系统打开的文件,因为lsof需要访问核心内存和各种文件,所以必须以root用户的身份运行它才能够充分地发挥其功能。


COMMANDPIDUSERFDTYPEDEVICESIZENODENAMEinit1rootcwdDIR3,310242/init1rootrtdDIR3,310242/init1roottxtREG3,3384321763452/sbin/initinit1rootmemREG3,31061141091620/lib/libdl-2.6.soinit1rootmemREG3,375606961091614/lib/libc-2.6.soinit1rootmemREG3,3794601091669/lib/libselinux.so.1init1rootmemREG3,32232801091668/lib/libsepol.so.1init1rootmemREG3,35641361091607/lib/ld-2.6.soinit1root10uFIFO0,151309/dev/initctl


每行显示一个打开的文件,若不指定条件默认将显示所有进程打开的所有文件。lsof输出各列信息的意义如下:


COMMAND:进程的名称PID:进程标识符USER:进程所有者FD:文件描述符,应用程序通过文件描述符识别该文件。如cwd、txt等TYPE:文件类型,如DIR、REG等DEVICE:指定磁盘的名称SIZE:文件的大小NODE:索引节点(文件在磁盘上的标识)NAME:打开文件的确切名称


其中FD列中的文件描述符cwd值表示应用程序的当前工作目录,这是该应用程序启动的目录,除非它本身对这个目录进行更改。

txt类型的文件是程序代码,如应用程序二进制文件本身或共享库,如上列表中显示的/sbin/init程序。其次数值表示应用

程序的文件描述符,这是打开该文件时返回的一个整数。如上的最后一行文件/dev/initctl,其文件描述符为10。u表示该

文件被打开并处于读取/写入模式,而不是只读®或只写(w)模式。同时还有大写的W表示该应用程序具有对整个文件的写

锁。该文件描述符用于确保每次只能打开一个应用程序实例。初始打开每个应用程序时,都具有三个文件描述符,从0到2,

分别表示标准输入、输出和错误流。所以大多数应用程序所打开的文件的FD都是从3开始。

与FD列相比,Type列则比较直观。文件和目录分别称为REG和DIR。而CHR和BLK,分别表示字符和块设备;

或者UNIX、FIFO和IPv4,分别表示UNIX域套接字、先进先出(FIFO)队列和网际协议(IP)套接字。

lsof常用参数


lsof常见的用法是查找应用程序打开的文件的名称和数目。可用于查找出某个特定应用程序将日志数据记录到何处,或者正在跟踪某个问题。

例如,linux限制了进程能够打开文件的数目。通常这个数值很大,所以不会产生问题,并且在需要时,应用程序可以请求更大的值(直到某

个上限)。如果你怀疑应用程序耗尽了文件描述符,那么可以使用lsof统计打开的文件数目,以进行验证。lsof语法格式是:


lsof[options]filename


常用的参数列表:


lsoffilename显示打开指定文件的所有进程lsof-a表示两个参数都必须满足时才显示结果lsof-cstring显示COMMAND列中包含指定字符的进程所有打开的文件lsof-uusername显示所属user进程打开的文件lsof-ggid显示归属gid的进程情况lsof+d/DIR/显示目录下被进程打开的文件lsof+D/DIR/同上,但是会搜索目录下的所有目录,时间相对较长lsof-dFD显示指定文件描述符的进程lsof-n不将IP转换为hostname,缺省是不加上-n参数lsof-i用以显示符合条件的进程情况lsof-i[46][protocol][@hostname|hostaddr][:service|port]46-->IPv4orIPv6protocol-->TCPorUDPhostname-->Internethostnamehostaddr-->IPv4地址service-->/etc/service中的servicename(可以不只一个)port-->端口号(可以不只一个)


例如:查看22端口现在运行的情况


#lsof-i:22COMMANDPIDUSERFDTYPEDEVICESIZENODENAMEsshd1409root3uIPv65678TCP*:ssh(LISTEN)


查看所属root用户进程所打开的文件类型为txt的文件:


#lsof-a-uroot-dtxtCOMMANDPIDUSERFDTYPEDEVICESIZENODENAMEinit1roottxtREG3,3384321763452/sbin/initmingetty1632roottxtREG3,3143661763337/sbin/mingettymingetty1633roottxtREG3,3143661763337/sbin/mingettymingetty1634roottxtREG3,3143661763337/sbin/mingettymingetty1635roottxtREG3,3143661763337/sbin/mingettymingetty1636roottxtREG3,3143661763337/sbin/mingettymingetty1637roottxtREG3,3143661763337/sbin/mingettykdm1638roottxtREG3,31325481428194/usr/bin/kdmX1670roottxtREG3,317163961428336/usr/bin/Xorgkdm1671roottxtREG3,31325481428194/usr/bin/kdmstartkde2427roottxtREG3,36454081544195/bin/bash......


lsof使用实例


一、查找谁在使用文件系统


在卸载文件系统时,如果该文件系统中有任何打开的文件,操作通常将会失败。那么通过lsof可以找出那些进程在使用当前要卸载的文件系统,如下:


#lsof/GTES11/COMMANDPIDUSERFDTYPEDEVICESIZENODENAMEbash4208rootcwdDIR3,140962/GTES11/vim4230rootcwdDIR3,140962/GTES11/


在这个示例中,用户root正在其/GTES11目录中进行一些操作。一个bash是实例正在运行,并且它当前的目录为/GTES11,另一个则显示的是vim正在编辑/GTES11下的文件。要成功地卸载/GTES11,应该在通知用户以确保情况正常之后,中止这些进程。这个示例说明了应用程序的当前工作目录非常重要,因为它仍保持着文件资源,并且可以防止文件系统被卸载。这就是为什么大部分守护进程(后台进程)将它们的目录更改为根目录、或服务特定的目录(如sendmail示例中的/var/spool/mqueue)的原因,以避免该守护进程阻止卸载不相关的文件系统。

二、恢复删除的文件


当Linux计算机受到入侵时,常见的情况是日志文件被删除,以掩盖攻击者的踪迹。管理错误也可能导致意外删除重要的文件,比如在清理旧日志时,意外地删除了数据库的活动事务日志。有时可以通过lsof来恢复这些文件。


当进程打开了某个文件时,只要该进程保持打开该文件,即使将其删除,它依然存在于磁盘中。这意味着,进程并不知道文件已经被删除,它仍然可以向打开该文件时提供给它的文件描述符进行读取和写入。除了该进程之外,这个文件是不可见的,因为已经删除了其相应的目录索引节点。

在/proc目录下,其中包含了反映内核和进程树的各种文件。/proc目录挂载的是在内存中所映射的一块区域,所以这些文件和目录并不存在于磁盘中,因此当我们对这些文件进行读取和写入时,实际上是在从内存中获取相关信息。大多数与lsof相关的信息都存储于以进程的PID命名的目录中,即/proc/1234中包含的是PID为1234的进程的信息。每个进程目录中存在着各种文件,它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他系统信息。lsof程序使用该信息和其他关于内核内部状态的信息来产生其输出。所以lsof可以显示进程的文件描述符和相关的文件名等信息。也就是我们通过访问进程的文件描述符可以找到该文件的相关信息。


当系统中的某个文件被意外地删除了,只要这个时候系统中还有进程正在访问该文件,那么我们就可以通过lsof从/proc目录下恢复该文件的内容。假如由于误操作将/var/log/messages文件删除掉了,那么这时要将/var/log/messages文件恢复的方法如下:

首先使用lsof来查看当前是否有进程打开/var/logmessages文件,如下:


#lsof|grep/var/log/messagessyslogd1283root2wREG3,353810171773647/var/log/messages(deleted)


从上面的信息可以看到PID1283(syslogd)打开文件的文件描述符为2。同时还可以看到/var/log/messages已经标记被删除了。因此我们可以在/proc/1283/fd/2(fd下的每个以数字命名的文件表示进程对应的文件描述符)中查看相应的信息,如下:


#head-n10/proc/1283/fd/2Aug413:50:15holmes86syslogd1.4.1:restart.Aug413:50:15holmes86kernel:klogd1.4.1,logsource=/proc/kmsgstarted.Aug413:50:15holmes86kernel:Linuxversion2.6.22.1-8(root@everestbuilder.linux-ren.org)(gccversion4.2.0)#1SMPWedJul1811:18:32EDT2007Aug413:50:15holmes86kernel:BIOS-providedphysicalRAMmap:Aug413:50:15holmes86kernel:BIOS-e820:0000000000000000-000000000009f000(usable)Aug413:50:15holmes86kernel:BIOS-e820:000000000009f000-00000000000a0000(reserved)Aug413:50:15holmes86kernel:BIOS-e820:0000000000100000-000000001f7d3800(usable)Aug413:50:15holmes86kernel:BIOS-e820:000000001f7d3800-0000000020000000(reserved)Aug413:50:15holmes86kernel:BIOS-e820:00000000e0000000-00000000f0007000(reserved)Aug413:50:15holmes86kernel:BIOS-e820:00000000f0008000-00000000f000c000(reserved)


从上面的信息可以看出,查看/proc/8663/fd/15就可以得到所要恢复的数据。如果可以通过文件描述符查看相应的数据,那么就可以使用I/O重定向将其复制到文件中,如:


cat/proc/1283/fd/2>/var/log/messages


对于许多应用程序,尤其是日志文件和数据库,这种恢复删除文件的方法非常有用。





4.Linuxiostat监测IO状态[转]

Linux系统出现了性能问题,一般我们可以通过top、iostat、free、vmstat等命令来查看初步定位问题。其中iostat可以给我们提供丰富的IO状态数据。

1.基本使用

$iostat-d-k110
参数-d表示,显示设备(磁盘)使用状态;-k某些使用block为单位的列强制使用Kilobytes为单位;110表示,数据显示每隔1秒刷新一次,共显示10次。

$iostat-d-k110

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn

sda39.2921.141.4444133980729990031

sda10.000.000.001623523

sda21.321.434.542983427394827104

sda36.300.8524.9517816289520725244

sda50.850.463.40954350370970116

sda60.000.000.00550236

sda70.000.000.004060

sda80.000.000.004060

sda90.000.000.004060

sda1060.6818.3571.433830022631490928140

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn

sda327.555159.18102.045056100

sda10.000.000.0000
tps:该设备每秒的传输次数(Indicatethenumberoftransferspersecondthatwereissuedtothedevice.)。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的。

kB_read/s:每秒从设备(driveexpressed)读取的数据量;kB_wrtn/s:每秒向设备(driveexpressed)写入的数据量;kB_read:读取的总数据量;kB_wrtn:写入的总数量数据量;这些单位都为Kilobytes。

上面的例子中,我们可以看到磁盘sda以及它的各个分区的统计数据,当时统计的磁盘总TPS是39.29,下面是各个分区的TPS。(因为是瞬间值,所以总TPS并不严格等于各个分区TPS的总和)

2.-x参数

使用-x参数我们可以获得更多统计信息。

iostat-d-x-k110

Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

sda1.5628.317.8031.4942.512.9221.261.461.160.030.792.6210.28

Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

sda2.0020.00381.007.0012320.00216.006160.00108.0032.311.754.502.1784.20
rrqm/s:每秒这个设备相关的读取请求有多少被Merge了(当系统调用需要读取数据的时候,VFS将请求发到各个FS,如果FS发现不同的读取请求读取的是相同Block的数据,FS会将这个请求合并Merge);wrqm/s:每秒这个设备相关的写入请求有多少被Merge了。

rsec/s:每秒读取的扇区数;wsec/:每秒写入的扇区数。r/s:Thenumberofreadrequeststhatwereissuedtothedevicepersecond;w/s:Thenumberofwrite
requeststhatwereissuedtothedevicepersecond;

await:每一个IO请求的处理的平均时间(单位是微秒)。这里可以理解为IO的响应时间,一般地系统IO响应时间应该低于5ms,如果大于10ms就比较大了。

%util:在统计时间内所有处理IO时间,除以总共统计时间。例如,如果统计间隔1秒,该设备有0.8秒在处理IO,而0.2秒闲置,那么该设备的%util=0.8/1=80%,所以该参数暗示了设备的繁忙程度。一般地,如果该参数是100%表示设备已经接近满负荷运行了(当然如果是多磁盘,即使%util是100%,因为磁盘的并发能力,所以磁盘使用未必就到了瓶颈)。

3.-c参数

iostat还可以用来获取cpu部分状态值:

iostat-c110

avg-cpu:%user%nice%sys%iowait%idle

1.980.000.3511.4586.22

avg-cpu:%user%nice%sys%iowait%idle

1.620.000.2534.4663.67
4.常见用法

$iostat-d-k110#查看TPS和吞吐量信息

iostat-d-x-k110#查看设备使用率(%util)、响应时间(await)

iostat-c110#查看cpu状态
5.实例分析

$$iostat-d-k1|grepsda10

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn

sda1060.7218.9571.533956376471493241908

sda10299.024266.67129.414352132

sda10483.844589.904117.1745444076

sda10218.003360.00100.003360100

sda10546.008784.00124.008784124

sda10827.0013232.00136.0013232136
上面看到,磁盘每秒传输次数平均约400;每秒磁盘读取约5MB,写入约1MB。

iostat-d-x-k1

Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

sda1.5628.317.8431.5043.653.1621.821.581.190.030.802.6110.29

sda1.9824.75419.806.9313465.35253.476732.67126.7332.152.004.702.0085.25

sda3.0641.84444.9054.0814204.082048.987102.041024.4932.572.104.211.8592.24
可以看到磁盘的平均响应时间<5ms,磁盘使用率>80。磁盘响应正常,但是已经很繁忙了。

参考文献:

Linuxmaniostat
HowLinuxiostatcomputesitsresults
Linuxiostat
http://blog.csdn.net/AE86_FC/archive/2010/02/03/5284112.aspx

最近要对分布式集群做一些性能测试,其中一个很重要的项就是测试hadoop分布式集群在支持多磁盘轮转写入的时候在各种磁盘配置的情况下的读写性能,如在RAID0,RAID5和JBOD情况下的磁盘性能,所以linux下的iostat命令就在产生report的脚本中非常有用,特此记录下iostat命令的一些使用


[命令:]iostat[-c|-d][-k][-t][间隔描述][检测次数]

参数:

-c:仅显示cpu的状态

-d:仅显示存储设备的状态,不可以和-c一起使用

-k:默认显示的是读入读出的block信息,用-k可以改成KB大小来显示

-t:显示日期

-pdevice|ALL:device为某个设备或者某个分区,如果使用ALL,就表示要显示所有分区和设备的信息

显示示例:

avg-cpu:%user%nice%sys%iowait%idle

4.550.000.630.2694.56

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn

cciss/c0d030.1168.2067.1312327840601213452142

cciss/c0d0p10.000.000.0025312

cciss/c0d0p283.7868.1867.1112325720111213204536

dm-01.060.604.071087320173555720

dm-182.5067.4262.2312187043091124966656

dm-20.210.180.83319960514929540

dm-30.000.000.00372224

以上显示分为上下两个部分,上半部分显示CPU的信息,下面的数据显示存储设备的相关数据,它的数据意义如下:

tps:平均每秒钟的传送次数,与数据传输“次数”相关,非容量

kB_read/s:启动到现在的平均读取单位

kB_wrtn/s:启动到现在的平均写入单位

kB_read:启动到现在总共读出来的文件单位

kB_wrtn:启动到现在总共写入的文件单位

如果想要对iostat检查多此,每次之间的间隔一定数量的秒数,这样就可以查看每几秒钟之内的io统计数据,这对性能的测试才具有实际意义:

$>iostat-d23

表示没量秒钟检查一次,一共检查三次

avg-cpu:%user%nice%sys%iowait%idle

4.550.000.630.2694.56

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn

cciss/c0d030.1168.2067.1312329002881213456210

cciss/c0d0p10.000.000.0025312

cciss/c0d0p283.7868.1967.1112326882391213208604

dm-01.060.604.071087320173558008

dm-182.5067.4262.2312188205371124967604

dm-20.210.180.83319960514930372

dm-30.000.000.00372224

avg-cpu:%user%nice%sys%iowait%idle

0.000.000.630.0099.37

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn

cciss/c0d01.020.0063.270124

cciss/c0d0p10.000.000.0000

cciss/c0d0p215.820.0063.270124

dm-015.820.0063.270124

dm-10.000.000.0000

dm-20.000.000.0000

dm-30.000.000.0000

avg-cpu:%user%nice%sys%iowait%idle

0.000.000.320.0099.68

Device:tpskB_read/skB_wrtn/skB_readkB_wrtn

cciss/c0d03.060.0026.53052

cciss/c0d0p10.000.000.0000

cciss/c0d0p26.630.0026.53052

dm-00.000.000.0000

dm-16.630.0026.53052

dm-20.000.000.0000

dm-30.000.000.0000

其中每一次的统计都是上一次的统计时间到这次的统计时间之间的统计数据



5.如何查看进程IO读写情况?

2009年08月26日|标签:linux,python|
作者:vpsee
LinuxKernel2.6.20以上的内核支持进程IO统计,可以用类似iotop这样的工具来监测每个进程对IO操作的情况,就像用top来实时查看进程内存、CPU等占用情况那样。但是对于2.6.20以下的Linux内核版本就没那么幸运了,根据StackOverflow的这篇回帖给出的方法,VPSee
写了一个简单的Python脚本用来在linuxkernel<2.6.20下打印进程IO状况。

Kernel<2.6.20

这个脚本的想法很简单,把dmesg的结果重定向到一个文件后再解析出来,每隔1秒钟打印一次进程IO读写的统计信息,执行这个脚本需要root:

#!/usr/bin/python
#Monitoringper-processdiskI/Oactivity
#writtenbyhttp://www.vpsee.com

importsys,os,time,signal,re

classDiskIO:
def__init__(self,pname=None,pid=None,reads=0,writes=0):
self.pname=pname
self.pid=pid
self.reads=0
self.writes=0

defmain():
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"TASKPIDREADWRITE"
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()
continue
found=False
foriteminl:
ifitem.pid==m.group(2):
found=True
ifm.group(3)=="READ":
item.reads=item.reads+1
elifm.group(3)=="WRITE":
item.writes=item.writes+1
ifnotfound:
l.append(DiskIO(m.group(1),m.group(2)))
line=f.readline()
time.sleep(1)
foriteminl:
print"%-10s%10s%10d%10d"%\
(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()



Kernel>=2.6.20

如果想用iotop来实时查看进程IO活动状况的话,需要下载和升级新内核(2.6.20或以上版本)。编译新内核时需要打开TASK_DELAY_ACCT和TASK_IO_ACCOUNTING选项。解压内核后进入配置界面:

#tarjxvflinux-2.6.30.5.tar.bz2
#mvlinux-2.6.30.5/usr/src/
#cd/usr/src/linux-2.6.30.5

#makemenuconfig

选择Kernelhacking–>Collectschedulerdebugginginfo和Collectschedulerstatistics,保存内核后编译内核:

#make;makemodules;makemodules_install;makeinstall

修改grub,确认能正确启动新内核:

#vi/boot/grub/menu.lst

出了新内核外,iotop还需要Python2.5或以上才能运行,所以如果当前Python是2.4的话需要下载和安装最新的Python包。这里使用源代码编译安装:

#tarjxvfPython-2.6.2.tar.bz2
#cdPython-2.6.2
#./configure
#make;makeinstall

别忘了下载setuptools:

#mvsetuptools-0.6c9-py2.6.egg.shsetuptools-0.6c9-py2.6.egg
#shsetuptools-0.6c9-py2.6.egg
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: