如何查看进程 IO 读写情况?
2009年08月26日 | 标签: linux, python | 作者:vpsee
Linux Kernel 2.6.20 以上的内核支持进程 IO 统计,可以用类似 iotop 这样的工具来监测每个进程对 IO 操作的情况,就像用 top 来实时查看进程内存、CPU 等占用情况那样。但是对于 2.6.20 以下的 Linux 内核版本就没那么幸运了,根据 Stack Overflow 的这篇回帖 给出的方法,VPSee 写了一个简单的 Python 脚本用来在 linux kernel < 2.6.20 下打印进程 IO 状况。
Kernel < 2.6.20
这个脚本的想法很简单,把 dmesg 的结果重定向到一个文件后再解析出来,每隔1秒钟打印一次进程 IO 读写的统计信息,执行这个脚本需要 root:
#!/usr/bin/python
# Monitoring per-process disk I/O activity
# written by http://www.vpsee.com
import sys, os, time, signal, re
class DiskIO:
def __init__(self, pname=None, pid=None, reads=0, writes=0):
self.pname = pname
self.pid = pid
self.reads = 0
self.writes = 0
def main():
argc = len(sys.argv)
if argc != 1:
print "usage: ./iotop"
sys.exit(0)
if os.getuid() != 0:
print "must be run as root"
sys.exit(0)
signal.signal(signal.SIGINT, signal_handler)
os.system('echo 1 > /proc/sys/vm/block_dump')
print "TASK PID READ WRITE"
while True:
os.system('dmesg -c > /tmp/diskio.log')
l = []
f = open('/tmp/diskio.log', 'r')
line = f.readline()
while line:
m = re.match(\
'^(\S+)\((\d+)\): (READ|WRITE) block (\d+) on (\S+)', line)
if m != None:
if not l:
l.append(DiskIO(m.group(1), m.group(2)))
line = f.readline()
continue
found = False
for item in l:
if item.pid == m.group(2):
found = True
if m.group(3) == "READ":
item.reads = item.reads + 1
elif m.group(3) == "WRITE":
item.writes = item.writes + 1
if not found:
l.append(DiskIO(m.group(1), m.group(2)))
line = f.readline()
time.sleep(1)
for item in l:
print "%-10s %10s %10d %10d" % \
(item.pname, item.pid, item.reads, item.writes)
def signal_handler(signal, frame):
os.system('echo 0 > /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 选项。解压内核后进入配置界面:
# tar jxvf linux-2.6.30.5.tar.bz2 # mv linux-2.6.30.5 /usr/src/ # cd /usr/src/linux-2.6.30.5 # make menuconfig
选择 Kernel hacking –> Collect scheduler debugging info 和 Collect scheduler statistics,保存内核后编译内核:
# make; make modules; make modules_install; make install
修改 grub,确认能正确启动新内核:
# vi /boot/grub/menu.lst
出了新内核外,iotop 还需要 Python 2.5 或以上才能运行,所以如果当前 Python 是 2.4 的话需要下载和安装最新的 Python 包。这里使用源代码编译安装:
# tar jxvf Python-2.6.2.tar.bz2 # cd Python-2.6.2 # ./configure # make; make install
别忘了下载 setuptools:
# mv setuptools-0.6c9-py2.6.egg.sh setuptools-0.6c9-py2.6.egg # sh setuptools-0.6c9-py2.6.egg
更多信息
如果想知道更多关于 block_dump 的信息,可以看看这篇 监测 Linux 进程的实时 IO 情况。使用 block_dump 的时候,最好能关掉 klogd 进程。
我有个问题
我运行了上面的脚本,测系统上运行程序,大量的是kjournald进程,我查了这个是ext3的日志进程,蛋有个很奇怪的问题,我要监测的一些计算程序,读写都是0,缺还是被记录下来了,而脚本里判断输出的规则好像是如果有读写才记录下来并显示,为什么会出现读写都是0的条目呢
嗯,会出现 WRITE 是0的情况,比如下面的就是直接从 dmesg -c 打印出来的:
pdflush(30744): WRITE block 0 on sdb1
所以有可能出现读写都是0的情况,比如上面的写是0,读没有,所以这个 iotop 脚本打印出来就是 READ WRITE 都为0了。
谢谢您的答复。那我还想问问,如果这个write是0,是不是可以说明这个时间点上没有write?或者说,这个脚本的循环,每次判定的时候,也就是1秒1秒这样判定,如果1.5秒时候有一个0.1秒的IO操作,是无法被识别出来的?
我现在在帮导师做一套计算平台的性能调优,主要是想通过这个东西,找出io瓶颈,之前装了iotop,能囧的没用起来,不能显示进程的,看到您博客里提供的脚本真是如获至宝,十分感谢。
和这个脚本无关,这个脚本只是来解析 dmesg 打印出来的结果的。抛开这个脚本不谈,让我们从原始数据(dmesg)说起,你直接从 dmesg 打印出结果也会出现 WRITE block 0 的情况,比如这是我系统上的输出:
pdflush(23123): WRITE block 0 on sdb1
pdflush(23123): WRITE block 16 on sdb1
pdflush(23123): WRITE block 104 on sdb1
pdflush(23123): WRITE block 40884480 on sdb1
pdflush(23123): WRITE block 43767360 on sdb1
pdflush(23123): WRITE block 43864648 on sdb1
默认情况下 pdflush 有2个进程在运行、每隔5秒被唤醒去检查是否需要 flush 脏数据到 sdb1,一种解释可能是 pdflush 被唤醒的时候发现没什么可 flush 的,做了 WRITE 动作但没有 WRITE 任何东西到 sdb1,所以 WRITE block 为 0
您说的的确是有可能,我这个iotop脚本的记录,同时还有配合了iostat和vmstat的记录数据,在同一时间点上,显示出几个计算程序的读写都为0,而cpu几乎是100%空闲,写操作只有1.17次。我准备在别的机器上再测试一下,这次的数据有点不正常,因为以前也测过数据和这次差别很大
好了,我查了一下 2.6.18 内核代码,内核用 dmesg 打印 IO 的这段代码在 ll_rw_blk.c 里面:
# vi linux-2.6.18/block/ll_rw_blk.c
…
if (unlikely(block_dump)) {
char b[BDEVNAME_SIZE];
printk(KERN_DEBUG “%s(%d): %s block %Lu on %s\n”,
current->comm, current->pid,
(rw & WRITE) ? “WRITE” : “READ”,
(unsigned long long)bio->bi_sector,
bdevname(bio->bi_bdev,b));
}
…
很明显从上面代码可以看出 WRITE block 0 on sdb1,这里的 0 是 bio->bi_sector,是 sector 不是 WRITE 了多少 blocks 的意思。
您的意思是这个0代表某个扇区?测试机器只有1个硬盘,难怪我看凡是系统进程以外的进程write里只会出现0,1,2,这三个数字,但是比如kjournald和pdflush这样的系统进程write里的数字都是不同的,多的时候能到2000多。不知道iotop这个程序能不能记录下进程的读写情况,我昨天拿到了一组测试数据,我发现硬盘高的时候,能连续100多秒保持在IO是100%占用,应该是很严重的瓶颈,我在想如果修改kjournald的模式能否有所缓解这种情况?
嗯,你看看这篇 监测 Linux 进程的实时 IO 情况。使用 block_dump 的时候,最好能关掉 klogd 进程。
非常感谢您的帮助
我想问下您,iotop这个工具,在2.6.20内核用起来了吗,我升级之后还是看不到内核,下面报错的问题,我Google上查了说是内核的bug,我想问下,您在什么系统上装的iotop,内核多少,我是redhat5.3
Linux kernel 版本太多我没有一一测过,不过 2.6.30 上(linux-2.6.30.5.tar.bz2)上是可以的。
谢谢