iostat和iowait

iostat和iowait[转]

十月 14th, 2011  发表在 linux系统 本文作者：深夜的蚊子

%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=125

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

转载自：扶凯: http://www.php-oa.com/2009/02/03/iostat.html 
以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器

$iostat -x 1

Linux 2.6.33-fukai (fukai-laptop)          _i686_    (2 CPU)

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

5.47    0.50    8.96   48.26    0.00   36.82



Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util

sda               6.00   273.00   99.00    7.00  2240.00  2240.00    42.26     1.12   10.57   7.96  84.40

sdb               0.00     4.00    0.00  350.00     0.00  2068.00     5.91     0.55    1.58   0.54  18.80

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压力高)

另外 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 的速度和响应时间。

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

# 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。

什么是inode？

来自：http://www.dbconf.net/inode-related-issues.html

inode是Linux/Unix系文件系统[如ext]中的一个概念，当一个文件系统格式化了以后，他一定会有 inode table 与 data area 两个区块。Block 是记录文件内容数据的地区，而 inode 则是记录该文件的属性、及该文件放置在哪一个 Block 之内的信息。而且每个文件至少需要一个inode。

如何查询一个文件系统的inode使用情况：

Filesystem            Inodes   IUsed   IFree IUse% Mounted on

/dev/sda1            2366400  186064 2180336    8% /

none                   63327       1   63326    1% /dev/shm

使用df -i可以看到文件系统的inode总数、使用数、剩余量和使用百分比。

如何查看每个文件系统的inode大小：

[root@gc_server ~]# dumpe2fs -h /dev/sda1|grep node

dumpe2fs 1.35 (28-Feb-2004)

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file

Inode count:              2366400

Free inodes:              2177496

Inodes per group:         16320

Inode blocks per group:   510

First inode:              11

Inode size:               128

Journal inode:            8

First orphan inode:       150509

Journal backup:           inode blocks

定义inode大小：

inode大小决定了一个文件系统中的inode总量，在创建文件系统的时候可以指定inode的大小，创建之后不可修改：

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文件.比如我们可以先看一下我的这块硬盘:

[root@localhost ~]# cat /sys/block/sda/queue/scheduler

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进行操作，如下所示：

cat /sys/block/sda/queue/scheduler

echo “cfq” > /sys/block/sda/queue/scheduler

来自：http://www.sar4.com/2011/02/25/iostat%E5%92%8Ciowait.html

© 2011, 深夜的蚊子. 版权所有. 如转载，请注明：转载自 蚊子空间[http://www.wenzizone.cn]