%
iowait并不能反应磁盘瓶颈
iowait实际测量的是cpu时间：
%
iowait = (cpu idle time)/(all cpu time)
这个文章说明：高速cpu会造成很高的iowait值，但这并不代表磁盘是系统的瓶颈。唯一能说明磁盘是系统瓶颈的方法，就是很高的read/write时间，一般来说超过20ms，就代表了不太正常的磁盘性能。为什么是20ms呢？一般来说，一次读写就是一次寻到+一次旋转延迟+数据传输的时间。由于，现代硬盘数据传输就是几微秒或者几十微秒的事情，远远小于寻道时间2~20ms和旋转延迟4~8ms，所以只计算这两个时间就差不多了，也就是15~20ms。只要大于20ms，就必须考虑是否交给磁盘读写的次数太多，导致磁盘性能降低了。
作者的文章以AIX系统为例，使用其工具filemon来检测磁盘每次读写平均耗时。在Linux下，可以通过
iostat命令还查看磁盘性能。其中的svctm一项，反应了磁盘的负载情况，如果该项大于15ms，并且util%接近100%，那就说明，磁盘现在是整个系统性能的瓶颈了。
来自：
http://blog.morebits.org/?p=125iostat来对linux硬盘IO性能进行了解
转载自：扶凯:
http://www.php-oa.com/2009/02/03/iostat.html以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器
1
2
3
4
5
6
7
8
$iostat -x 1<br/>
Linux 2.6.33-fukai (fukai-laptop) _i686_ (2 CPU)<br/>
avg-cpu: %user %nice %system %iowait %steal %idle<br/>
5.47 0.50 8.96 48.26 0.00 36.82<br/>
<br/>
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util<br/>
sda 6.00 273.00 99.00 7.00 2240.00 2240.00 42.26 1.12 10.57 7.96 84.40<br/>
sdb 0.00 4.00 0.00 350.00 0.00 2068.00 5.91 0.55 1.58 0.54 18.80
1
2
3
4
5
6
7
8
9
10
11
12
13
rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s<br/>
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s<br />
r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s<br/>
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s<br/>
rsec/s: 每秒读扇区数。即 delta(rsect)/s<br/>
wsec/s: 每秒写扇区数。即 delta(wsect)/s<br/>
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)<br/>
wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)<br/>
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)<br/>
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。<br/>
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)<br/>
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)<br/>
%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压力高)
另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 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 洪水。
别人一个不错的例子(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 的速度和响应时间。
下面是别人写的这个参数输出的分析
1
2
3
4
5
6
# iostat -x 1<br/>
avg-cpu: %user %nice %sys %idle<br/>
16.24 0.00 4.31 79.44<br/>
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util<br/>
/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。
什么是inode？
来自：
http://www.dbconf.net/inode-related-issues.htmlinode是Linux/Unix系文件系统[如ext]中的一个概念，当一个文件系统格式化了以后，他一定会有 inode table 与 data area 两个区块。Block 是记录文件内容数据的地区，而 inode 则是记录该文件的属性、及该文件放置在哪一个 Block 之内的信息。而且每个文件至少需要一个inode。
如何查询一个文件系统的inode使用情况：
1
2
3
Filesystem Inodes IUsed IFree IUse% Mounted on<br/>
/dev/sda1 2366400 186064 2180336 8% /<br/>
none 63327 1 63326 1% /dev/shm
使用df -i可以看到文件系统的inode总数、使用数、剩余量和使用百分比。
如何查看每个文件系统的inode大小：
1
2
3
4
5
6
7
8
9
10
11
12
[root@gc_server ~]# dumpe2fs -h /dev/sda1|grep node<br/>
dumpe2fs 1.35 (28-Feb-2004)<br/>
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file<br/>
Inode count: 2366400<br/>
Free inodes: 2177496<br/>
Inodes per group: 16320<br/>
Inode blocks per group: 510<br/>
First inode: 11<br/>
Inode size: 128<br/>
Journal inode: 8<br/>
First orphan inode: 150509<br/>
Journal backup: inode blocks
定义inode大小：
inode大小决定了一个文件系统中的inode总量，在创建文件系统的时候可以指定inode的大小，创建之后不可修改：
1
mkfs.ext3 -I 128 /dev/sdb5 //自定inode的大小为128byte
inode会引起什么问题：
可能出现磁盘空闲空间充足的情况下，新建文件时提示磁盘空间满。
inode数量过多由什么引起：
一般是小文件过多，如果一个文件大小比文件系统的块大小还小，如文件系统的block size为4k，而文件只有2k，则有2k的空间被浪费，也就是blocks per inode ratio过小，从而有可能会出现磁盘空间未满，而inode数消耗殆尽的情况。
如何规划：
因为inode大小一般而言略大于block大小为宜，所以：
1、 当 block 越小、inodes 越多，可利用空间越多，但是大文件写入效率较差：适合文件数量多但是文件容量小的系统，例如 BBS 或者新闻群组 news 这方面的服务之系统；
2、 当 block 越大 、 inodes 数越少，大文件写入效率较佳，但浪费的空间较多：适合文件容量大的系统。
IO调度器
IO调度器的总体目标是希望让磁头能够总是往一个方向移动,移动到底了再往反方向走,这恰恰就是现实生活中的电梯模型,所以IO调度器也被叫做电梯.(elevator)而相应的算法也就被叫做电梯算法.而Linux中IO调度的电梯算法有好几种,一个叫做as(Anticipatory),一个叫做cfq(Complete Fairness Queueing),一个叫做deadline,还有一个叫做noop(No Operation).具体使用哪种算法我们可以在启动的时候通过内核参数elevator来指定.
另一方面我们也可以单独的为某个设备指定它所采用的IO调度算法,这就通过修改在/sys/block/sda/queue/目录下面的scheduler文件.比如我们可以先看一下我的这块硬盘:
1
2
[root@localhost ~]# cat /sys/block/sda/queue/scheduler<br/>
noop anticipatory deadline [cfq]
可以看到我们这里采用的是cfq.
Linux IO调度器相关算法介绍
IO调度器（IO Scheduler）是操作系统用来决定块设备上IO操作提交顺序的方法。存在的目的有两个，一是提高IO吞吐量，二是降低IO响应时间。然而IO吞吐量和IO响应时间往往是矛盾的，为了尽量平衡这两者，IO调度器提供了多种调度算法来适应不同的IO请求场景。其中，对数据库这种随机读写的场景最有利的算法是DEANLINE。接着我们按照从简单到复杂的顺序，迅速扫一下Linux 2.6内核提供的几种IO调度算法。
1、NOOP
NOOP算法的全写为No Operation。该算法实现了最最简单的FIFO队列，所有IO请求大致按照先来后到的顺序进行操作。之所以说“大致”，原因是NOOP在FIFO的基础上还做了相邻IO请求的合并，并不是完完全全按照先进先出的规则满足IO请求。
假设有如下的io请求序列：
100，500，101，10，56，1000
NOOP将会按照如下顺序满足：
100(101)，500，10，56，1000
2、CFQ
CFQ算法的全写为Completely Fair Queuing。该算法的特点是按照IO请求的地址进行排序，而不是按照先来后到的顺序来进行响应。
假设有如下的io请求序列：
100，500，101，10，56，1000
CFQ将会按照如下顺序满足：
100，101，500，1000，10，56
在传统的SAS盘上，磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序，以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下，SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是，先来的IO请求并不一定能被满足，可能会出现饿死的情况。
3、DEADLINE
DEADLINE在CFQ的基础上，解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外，DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms，写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高，，而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下：
FIFO(Read) > FIFO(Write) > CFQ
4、ANTICIPATORY
CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求，比如顺序读，并没有做优化。为了满足随机IO和顺序IO混合的场景，Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上，为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求，就可以立即满足。
IO调度器算法的选择，既取决于硬件特征，也取决于应用场景。
在传统的SAS盘上，CFQ、DEADLINE、ANTICIPATORY都是不错的选择；对于专属的数据库服务器，DEADLINE的吞吐量和响应时间都表现良好。然而在新兴的固态硬盘比如SSD、Fusion IO上，最简单的NOOP反而可能是最好的算法，因为其他三个算法的优化是基于缩短寻道时间的，而固态硬盘没有所谓的寻道时间且IO响应时间非常短。
查看和修改IO调度器的算法非常简单。假设我们要对sda进行操作，如下所示：
1
2
cat /sys/block/sda/queue/scheduler<br/>
echo “cfq” > /sys/block/sda/queue/scheduler
来自：
http://www.sar4.com/2011/02/25/iostat%E5%92%8Ciowait.html2011,
深夜的蚊子. 版权所有. 如转载，请注明：转载自
蚊子空间
[http://www.wenzizone.cn]相关文章：
Linux System and Performance Monitoring(I/O篇)[转] Linux System and Performance Monitoring(总结篇)[转] 脚本分享--linux下磁盘io测试 nagios监控iostat[技术]
