1. 关于Linux系统指令 top 之 %wa 占用高，用`iostat`探个究竟
最近测试一项目，性能非常不理想。老版本逻辑和功能都简单时，性能是相当的好！接口点击率是万级的。谁知修改后上不了百。
架设Jboss服务器，业务逻辑用Java处理，核心模块使用C++处理，使用JNI衔接。
本应用对CPU和硬盘第三非常敏感，因为有压缩解压和大量数据交互。起初作压力测试时，发现服务器各资源使用都有剩余，而点击率曲线波动却非常大，简单看似乎是应用程序有问题。
使用top查看Cpu各核的使用情况，发现一个非常诡异的现象：
1. 经常只有部分核是满载的，另外一部分基本空闲；
2. 在CPU满载时，%wa 的波动比较大，有时会占到较大比例。
所以，监控整个CPU时会发现CPU使用率不高，实际上任务总是分派到某个核上且导致对应核满载。无法有效使用CPU，其它资源自然也难以有效调度。
废话不多说，%wa指CPU等待磁盘写入完成的时间。莫非是磁盘忙，怎样证明是磁盘在忙？
首先看下%wa的解释：Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.
起初用`lsof | less`查看文件的读写情况，发现/tmp目录下有大量文件读写。经查证，是Jboss处理上传文件会默认写入到/tmp文件夹，然后再执行了一次拷贝到程序读取的目录。修改Jboss配置直接写入到程序读写目录，性能没有本质上的改变。
关于CPU使用波动大，我们也在程序内部加了很多计时器，发现某些模块在处理并发时会有响应时间很长的情况，这点证实了为什么点击率波动很大。
但此模块进行单进程串行测试时，每秒完成事务数是相当可观的。一个进程每秒完成的事务数都比当前测试点击率要高很多！使用多进程来测试此模块时，发现“进程数=核数”时效果最佳。于是在Java层控制同时进入此模块的数量，毕竟Java是调用JNI来使用此模块，使用全局锁来控制并发，最终结果没有想象的那么理想，但明显可以看出：通过控制并发数，能有效提高CPU的使用率，点击率也上升了一些。
另外一个问题就是，CPU会出现一会满载，一会空闲的情况，导致点击率曲线仍然波动大的问题。商讨后决定在C++代码中加入“释放CPU控制权”的逻辑，这样就在代码层来作了一个负载均衡。点击率波动的问题得到了好转，但点击率仍然不理想，预期瓶颈是网络而实际变成了CPU。
优化了压缩解决的处理后，性能没有明显提升。这时我才想起%wa，我还没有进一步证明是磁盘的闲忙程度。使用了一些监控工具，诸如：vmstat、sar、dstat、sysstat没有发现对磁盘作非常详细的监控。最后试了下iostat，搞定！
iostat的编译非常简单，就一个c文件，MakeFile里作者写了一句话“Cann't be simpler”。直接make install就在目录下生成了iostat的可执行文件，看一下帮助，执行 `iostat -cdDx 10` 。其中有一列“%b”描述了磁盘的闲忙程序，简单直接。另外还有详细的磁盘IO读写数据，帮助里也解释得非常清楚。
再进行一次压力测试，拿着这份数据，已经绝对性的说明问题了。此时那些大牛把代码改了一下，性能立马就上去了，千兆网络直接成为系统瓶颈。并于Java的控制问题，改用Apache直接编译程序模块调用，完成变为可控，问题瞬间解决！
附上iostat的源码：
转自：http://hi.baidu.com/higkoo/blog/item/d4f7f822e7871cf8d6cae25e.html
以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器
# iostat -x 1 10
Linux 2.6.18-92.el5xen 02/03/2009
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.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 -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.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. linux lsof详解
3. -c 参数iostat还可以用来获取cpu部分状态值：
iostat -c 1 10
avg-cpu: %user %nice %sys %iowait %idle
1.98 0.00 0.35 11.45 86.22
avg-cpu: %user %nice %sys %iowait %idle
1.62 0.00 0.25 34.46 63.674. 常见用法
$iostat -d -k 1 10 #查看TPS和吞吐量信息
iostat -d -x -k 1 10 #查看设备使用率（%util）、响应时间（await）
iostat -c 1 10 #查看cpu状态5. 实例分析
$$iostat -d -k 1 |grep sda10
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda10 60.72 18.95 71.53 395637647 1493241908
sda10 299.02 4266.67 129.41 4352 132
sda10 483.84 4589.90 4117.17 4544 4076
sda10 218.00 3360.00 100.00 3360 100
sda10 546.00 8784.00 124.00 8784 124
sda10 827.00 13232.00 136.00 13232 136上面看到，磁盘每秒传输次数平均约400；每秒磁盘读取约5MB，写入约1MB。
iostat -d -x -k 1
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 1.56 28.31 7.84 31.50 43.65 3.16 21.82 1.58 1.19 0.03 0.80 2.61 10.29
sda 1.98 24.75 419.80 6.93 13465.35 253.47 6732.67 126.73 32.15 2.00 4.70 2.00 85.25
sda 3.06 41.84 444.90 54.08 14204.08 2048.98 7102.04 1024.49 32.57 2.10 4.21 1.85 92.24可以看到磁盘的平均响应时间<5ms，磁盘使用率>80。磁盘响应正常，但是已经很繁忙了。
参考文献：
- Linux man iostat
- How Linux iostat computes its results
- Linux iostat
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 : 显示日期
-p device | ALL : device为某个设备或者某个分区，如果使用ALL，就表示要显示所有分区和设备的信息
显示示例：
avg-cpu: %user %nice %sys %iowait %idle
4.55 0.00 0.63 0.26 94.56
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 30.11 68.20 67.13 1232784060 1213452142
cciss/c0d0p1 0.00 0.00 0.00 2531 2
cciss/c0d0p2 83.78 68.18 67.11 1232572011 1213204536
dm-0 1.06 0.60 4.07 10873201 73555720
dm-1 82.50 67.42 62.23 1218704309 1124966656
dm-2 0.21 0.18 0.83 3199605 14929540
dm-3 0.00 0.00 0.00 372 224
以上显示分为上下两个部 分，上半部分显示CPU的信息，下面的数 据显示存储设备的相关数据，它的数据意义如下：
tps：平均每秒钟的传送次数，与数据传输“次数”相关，非容 量
kB_read/s：启动到现在的平均读取单位
kB_wrtn/s：启动到现在的平均写入单位
kB_read：启动到现在总共 读出来的文件单位
kB_wrtn： 启动到现在总共写入的文件单位
如果想要对iostat检查多此，每次之间的间隔一定数量的秒数，这样就可以查看每几秒钟之内的io统计数 据，这对性能的测试才具有实际意义：
$> iostat -d 2 3
表示没量秒钟检查一次，一共检查三次
avg-cpu: %user %nice %sys %iowait %idle
4.55 0.00 0.63 0.26 94.56
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 30.11 68.20 67.13 1232900288 1213456210
cciss/c0d0p1 0.00 0.00 0.00 2531 2
cciss/c0d0p2 83.78 68.19 67.11 1232688239 1213208604
dm-0 1.06 0.60 4.07 10873201 73558008
dm-1 82.50 67.42 62.23 1218820537 1124967604
dm-2 0.21 0.18 0.83 3199605 14930372
dm-3 0.00 0.00 0.00 372 224
avg-cpu: %user %nice %sys %iowait %idle
0.00 0.00 0.63 0.00 99.37
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 1.02 0.00 63.27 0 124
cciss/c0d0p1 0.00 0.00 0.00 0 0
cciss/c0d0p2 15.82 0.00 63.27 0 124
dm-0 15.82 0.00 63.27 0 124
dm-1 0.00 0.00 0.00 0 0
dm-2 0.00 0.00 0.00 0 0
dm-3 0.00 0.00 0.00 0 0
avg-cpu: %user %nice %sys %iowait %idle
0.00 0.00 0.32 0.00 99.68
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 3.06 0.00 26.53 0 52
cciss/c0d0p1 0.00 0.00 0.00 0 0
cciss/c0d0p2 6.63 0.00 26.53 0 52
dm-0 0.00 0.00 0.00 0 0
dm-1 6.63 0.00 26.53 0 52
dm-2 0.00 0.00 0.00 0 0
dm-3 0.00 0.00 0.00 0 0
其中每一次的统计都是上 一次的统计时间到这次的统计时间之间的统计数据
5. 如何查看进程 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 进程
lsof -i :22 知道22端口现在运行什么程序
lsof -c nsd 显示nsd进程现在打开的文件
lsof -g gid 显示归属gid的进程情况
lsof +d /usr/local/ 显示目录下被进程开启的文件
lsof +D /usr/local/ 同上，但是会搜索目录下的目录，时间较长
lsof -d 4 显示使用fd为4的进程
lsof -i 用以显示符合条件的进程情况
语法: lsof -i[46] [protocol][@hostname|hostaddr][:service|port]
46 --> IPv4 or IPv6
protocol --> TCP or UDP
hostname --> Internet host name
hostaddr --> IPv4位置
service --> /etc/service中的 service name (可以不只一個)
port --> 埠號 (可以不只一個)
例子: TCP:25 - TCP and port 25
@1.2.3.4 - Internet IPv4 host address 1.2.3.4
tcp@ohaha.ks.edu.tw:ftp - TCP protocol host:ohaha.ks.edu.tw service name:ftp
lsof -n 不将IP转换为hostname，预设是不加上-n参数
例子: lsof -i tcp@ohaha.ks.edu.tw:ftp -n
lsof -p 12 看进程号为12的进程打开了哪些文件
lsof +|-r [t] 控制lsof不断重复执行，缺省是15s刷新
-r，lsof会永远不断的执行，直到收到中断讯号
+r，lsof会一直执行，直到没有档案被显示
例子：不断查看目前ftp连接的情况：lsof -i tcp@ohaha.ks.edu.tw:ftp -r
lsof -s 列出打开文件的大小，如果没有大小，则留下空白
lsof -u username 以UID，列出打开的文件