概述
对于I/O-bond类型的进程，我们经常用iostat工具查看进程IO请求下发的数量、系统处理IO请求的耗时，进而分析进程与操作系统的交互过程中IO方面是否存在瓶颈。
同vmstat一样，iostat也有一个弱点，就是它不能对某个进程进行深入分析，仅对系统的整体情况进行分析。iostat属于sysstat软件包。可以用yum install sysstat 直接安装。
通过iostat方便查看CPU、网卡、tty设备、磁盘、CD-ROM 等等设备的活动情况, 负载信息。
解释
iostat各个参数说明:
-c 仅显示CPU统计信息.与-d选项互斥.
-d 仅显示磁盘统计信息.与-c选项互斥.
-k 以K为单位显示每秒的磁盘请求数,默认单位块.(512字节)
-m 以M为单位显示
-p device | ALL 与-x选项互斥,用于显示块设备及系统分区的统计信息.也可以在-p后指定一个设备名,如: # iostat -p hda 或显示所有设备 # iostat -p ALL -t 在输出数据时,打印搜集数据的时间.
-V 打印版本号和帮助信息.
-x 输出扩展信息.
-N 显示磁盘阵列(LVM) 信息
-n 显示NFS 使用情况
-p[磁盘] 显示磁盘和分区的情况
-t 显示终端和CPU的信息
cpu属性值说明：
%user：CPU处在用户模式下的时间百分比。
%nice：CPU处在带NICE值的用户模式下的时间百分比。
%system：CPU处在系统模式下的时间百分比。
%iowait：CPU等待输入输出完成时间的百分比。
%steal：管理程序维护另一个虚拟处理器时，虚拟CPU的无意识等待时间百分比。
%idle：CPU空闲时间百分比。
备注：如果%iowait的值过高，表示硬盘存在I/O瓶颈，%idle值高，表示CPU较空闲，如果%idle值高但系统响应慢时，有可能是CPU等待分配内存，此时应加大内存容量。%idle值如果持续低于10，那么系统的CPU处理能力相对较低，表明系统中最需要解决的资源是CPU。
disk属性值说明：
rrqm/s: 每秒进行 merge 的读操作数目。即 rmerge/s
wrqm/s: 每秒进行 merge 的写操作数目。即 wmerge/s
r/s: 每秒完成的读 I/O 设备次数。即 rio/s
w/s: 每秒完成的写 I/O 设备次数。即 wio/s
rsec/s: 每秒读扇区数。即 rsect/s
wsec/s: 每秒写扇区数。即 wsect/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。
wkB/s: 每秒写K字节数。是 wsect/s 的一半。
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。
%util: 一秒中有百分之多少的时间用于 I/O 操作，即被io消耗的cpu百分比，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
tps：该设备每秒的传输次数（Indicate the number of transfers per second that were issued to the device.）。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的。
我们可以看到磁盘sda以及它的各个分区的统计数据，当时统计的磁盘总TPS是22.73，下面是各个分区的TPS。（因为是瞬间值，所以总TPS并不严格等于各个分区TPS的总和）
备注：如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。另外await的参数也要多和svctm来参考。差的过高就一定有 IO 的问题。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明I/O 队列太长，io响应太慢，则需要进行必要优化。如果avgqu-sz比较大，也表示有当量io在等待。idle小于70% IO压力就较大了,一般读取速度有较多的wait。同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)，avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，如果次数多，但数据拿的小的话，其实 IO 也会很小.如果数据拿的大，才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲，读定速度是这个来决定的。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 洪水。
%iowait并不能反应磁盘瓶颈
iowait实际测量的是cpu时间：
%iowait = (cpu idle time)/(all cpu time)
svctm反应了磁盘的负载情况，如果该项大于15ms，并且util%接近100%，那就说明，磁盘现在是整个系统性能的瓶颈了。
高速cpu会造成很高的iowait值，但这并不代表磁盘是系统的瓶颈。唯一能说明磁盘是系统瓶颈的方法，就是很高的read/write时间，一般来说超过20ms，就代表了不太正常的磁盘性能。为什么是20ms呢？一般来说，一次读写就是一次寻到+一次旋转延迟+数据传输的时间。由于，现代硬盘数据传输就是几微秒或者几十微秒的事情，远远小于寻道时间2~20ms和旋转延迟4~8ms，所以只计算这两个时间就差不多了，也就是15~20ms。只要大于20ms，就必须考虑是否交给磁盘读写的次数太多，导致磁盘性能降低了。
如果磁盘显示长时间的高reads/writes，并且磁盘的percentage busy (%b)也远大于5%，同时average service time (svc_t)也远大于30milliseconds，这以下的措施需要被执行：
1.)调整应用，令其使用磁盘i/o更加有效率，可以通过修改磁盘队列、使用应用服务器的cache
2.)将文件系统分布到2个或多个磁盘上，并使用volume manager/disksuite的条带化特点
3.) 增加系统参数值，如inode cache , ufs_ninode。Increase the system parameter values for inode cache , ufs_ninode , which
is Number of inodes to be held in memory. Inodes are cached globally (for UFS), not on a per-file system basis
4.) 将文件系统移到更快的磁盘/控制器，或者用更好的设备来代替
查看文件系统块
做了lvm的分区，就不能查看pv了，而是查看lv了，也就是说要查与文件系统直接相关的设备名，也就是说文件系统是装在lv上的，不是装在分区/dev/sda2上的，所以查不出
查看块大小时都是基于文件系统信息的，有了文件系统才可以查看这些信息
15:42:13 4 ~:#tune2fs -l /dev/sda2|grep Block
tune2fs: Bad magic number in super-block while trying to open /dev/sda2
Couldn't find valid filesystem superblock.
15:42:36 5 ~:#tune2fs -l /dev/mapper/VolGroup-lv_root |grep Block
Block count: 3811328
Block size: 4096
Blocks per group: 32768
15:43:38 9 ~:#tune2fs -l /dev/VolGroup/lv_root |grep Block
Block count: 3811328
Block size: 4096
Blocks per group: 32768
windows7下以管理员运行cmd
输入命令：fsutil fsinfo ntfsinfo c: 来查看win的块大小
tps
Indicate the number of transfers per second that were issued to the device. A transfer is an I/O request to the device. Multiple logical
requests can be combined into a single I/O request to the device. A transfer is of indeterminate size.
indeterminate 不确定的，模糊的
iostat -d 1 以默认单位即块=512字节来显示
Blk_read/s
Indicate the amount of data read from the device expressed in a number of blocks per second. Blocks are equivalent to sectors with 2.4
kernels and newer and therefore have a size of 512 bytes. With older kernels, a block is of indeterminate size.
iostat -kd 1 以k为单位来显示
kB_read/s
Indicate the amount of data read from the device expressed in kilobytes per second.
物理设备
iostat -d 1
lvm
iostat -N 1
nfs
iostat -n 1
rBlk_nor/s
Indicate the number of blocks read by applications via the read(2) system call interface. A block has a size of 512 bytes.
样例
# iostat 显示一条统计记录,包括所有的CPU和设备.
# iostat -d 2 每隔2秒,显示一次设备统计信息.
# iostat -d 2 6 每隔2秒,显示一次设备统计信息.总共输出6次.
# iostat -x hda hdb 2 6 每隔2秒显示一次hda,hdb两个设备的扩展统计信息,共输出6次.
# iostat -p sda 2 6 每隔2秒显示一次sda及上面所有分区的统计信息,共输出6次.
# iostat -x -k -d 1
# iostat -xtc 5 2
[root@rac01 ~]# iostat -d sdf1 -k -x 2
Linux 2.6.18-308.el5 (rac01) 04/10/14
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdf1 27.50 160.50 75.00 416.50 20768.00 15725.75 148.50 17.69 34.76 0.47 23.30
对于以上示例输出，我们可以获取到以下信息：
1.每秒向磁盘上写15M左右数据(wkB/s值)
2.每秒有491次IO操作(r/s+w/s)，其中以写操作为主体
3.平均每次IO请求等待处理的时间为34.76毫秒，处理耗时为0.47毫秒
4.等待处理的IO请求队列中，平均有17.69个请求驻留
以上各值之间也存在联系，我们可以由一些值计算出其他数值，例如：
util = (r/s+w/s) * (svctm/1000)
对于上面的例子有：util = (75+416)*(0.47/1000) = 0.23077
案例
Linux性能监控情况1：同一时间进行大量的I/O操作
在这种情况时我们会发现CPU的wa时间百分比会上升，证明系统的idle时间大部分都是在等待I/O操作。
我们会用到工具top，vmstat，iostat，sar等。每一个工具的输出都从不同的方面反映出系统的性能情况。
Linux性能监控情况2：管道太小
任何I/O操作都需要一定的时间，而且这些时间对于硬盘来说是确定的，
它包含磁盘旋转的延时RD（rotation delay）和磁头搜索时间DS（disk seek）。
RD由磁盘转速（RPM）决定。RD是磁盘旋转一周所需时间的一半。如RPM为10000.
RPS=RPM/60=166
1/166=0.0006=6ms 磁盘旋转一周要6毫秒
RD=6ms/2=3ms
磁盘平均搜索时间是3ms，数据传输的平均延时是2ms，这样一次I/O操作的平均时间是：
3ms+3ms+2ms=8ms
IOPS=1000/8=125 这块磁盘的每秒IO数（IOPS）为125。所以对于10000RPM的磁盘来说它所能承受的IO操作在IOPS在120～150之间。
如果系统的I/O请求超过这个值，就会使磁盘成为系统的瓶颈。
对于系统而言有两种不同种类的I/O压力，连续I/O和随机I/O。
连续I/O常常出现在企业级数据库这样的应用中，需要连续的读取大量数据。这种系统的性能依靠它读取和移动数据的大小和快慢，
我们用iostat来监控，会发现rKB/s,wKB/s会很高。
随机I/O的系统来说性能的关注点不在搜传输数据的大小和速度，而是在磁盘的IOPS。这类系统的I/O请求比较小但是数量很大，
如Web服务器和Mail服务器。他们的性能主要依赖每秒钟可处理的请求数：
因此对于连续I/O系统来说我们要关注系统读取大量数据的能力即KB per request.对于随机I/O系统我们注重IOPS值.
别人一个不错的例子(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
上面的 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。
io层次模型
一次io在系统路径上的每个层次都有自己的定义，io层次不一样
过程分析
app做的一次io,请将某个文件读到我的缓冲区中
app>os
引发fs>磁盘控制器驱动程序的两次io
如果在这一层中间再加上lvm之类的卷管理层 磁控程序>磁盘（用信号驱动控制器），一次完整的scsi读或写，这是最细粒度的io
如果在这一层中间再加上raid层， 每加一层，那么上一层的一次io往往会演变为下一层的多次io
物理io概念，iops相关概念
连续io,随机io
写比读慢
磁盘的物理属性
常见硬盘IOPS参考值(数据仅供参考)：
---------------------------------------------------------------------
2,5" 10.000 rpm SAS 113 IOPS
2,5" 15.000 rpm SAS 156 IOPS
3,5" 15.000 rpm SAS 146 IOPS
2,5" 5.400 rpm SATA 71 IOPS
3,5" 7.200 rpm SATA 65 IOPS
3,5" 10.000 rpm U320 104 IOPS
3,5" 15.000 rpm U320 141 IOPS
3,5" 10.000 rpm FC 125 IOPS
3,5" 15.000 rpm FC 150 IOPS
3,5" 10.000 rpm FATA 119 IOPS
raid计算器
http://www.wmarow.com/strcalc/raidslider.html
磁盘iops详解
http://elf8848.iteye.com/blog/1731301