iostat 测试出存储的性能问题

持续性没有关系的，只要有I/O连续不断，就一定会很高。如果你去看VNX (你是VNX吧？)上LUN的Utilization，那么也必然是100%，它只是说这个对象在一定的时间内一直在工作，但这个工作量是否会过载他，这个参数并不能说明。

有量化指标，但问题是你是否知道这个量是多少。通常来说，响应时间、IOPS、MB/s这个三个值就是用来判断是否达到你的标准的参数。所以我刚才列出了await = 16.41ms这个值来说明响应时间应该是好的，从存储级别来看，响应<20ms一般都是正常的。更何况你是归档应用，对响应的要求并不高，相反对MB/s要求比较高。

所以，如果你手边没有量化值，就先体验一下嘛，大部分用户并不是从量化值来判断出性能问题，而是亲身感受到了缓慢，才会报告问题。比如原先归档同样数量的数据需要1小时，现在需要2小时，那可能需要再去判断，仅仅从iostate的Utilization来判断是不正确的。

1. 你指的严重性能问题是如何判断的？归档时间急剧变长？

2. await = 16.41ms，很正常；Utilization = 99.90只能说明在给定时间内设备一直在处理I/O，并不说明性能存在问题

是否能在详细描述下你是如何判断出存在性能问题的？

但是utilization=99.9这个值是持续性的，一直都在做io处理的问题。关于性能问题的界定，是否有一个量化的指标？

await (平均每次设备I/O操作的等待时间) 16.41ms (相比5ms)稍高，svctm (平均每次设备I/O操作的服务时间) 5ms正常。5ms的服务时间与你在存储上看到的结果相符(整体IO以及带宽并不高，那说明LUN的各方面性能指标正常：只要到了存储的I/O很快就能处理完)。等待时间稍高可能是I/O队列太长，归档软件是自己写的还是用的哪家的？看看软件厂商有什么优化方法吧，存储端从目前的信息来看没有性能问题。

顺便问一下是iSCSI还是FC？

先解释下每个字段的含义：

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的单位为毫秒)

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

  13.43 0.00 5.37 12.99 0.00 68.21

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

sdb 22.00 1468.00 140.00 141.00 30352.00 11824.00 150.09 4.63 16.41 3.56 99.90

%util =99.9,说明产生的I/O请求太多，该磁盘可能存在瓶颈.
CPU idle小于70% IO压力比较明显,我们要关注下读写wait.

通过对比await和svctm看出.差的过高可能有 IO 的问题，单次的I/O请求主要是在队列中等待而不是进过真正的读写，因为16.41远大于3.56.
那么来看队列，avgqu-sz=4.63，其实这个I/O队列并不长，比较短。既然队列不长，为什么还要等呢？

看到avgrq-sz这个就是直接每次操作的数据的大小,通过avgrq-sz、 r/s和w/s的数值说明了单次读写操作要拿的数据很频繁也很大，那么到底是读引起的还是写引起的呢？

继续看rsec/s wsec/s的数值，发觉是读的扇区远大于写的扇区，虽然写操作覆盖的扇区也很大了，同时rrqm/s wrqm/s的读操作被merge的数目很少，而写操作被merge的数目极大（说明下merge的含义：当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge），好了结合在一起就说明要读的数据很分散，在不同的扇区不同的block，没有被merge。

所以在队列不长的情况下，系统没有花很多时间在真正的拿数据上，而是因为一次I/O要拿很多的数据，偏偏又要在物理磁盘上寻找原本就很分散的数据。这就是现在的状况。

所以一方面，要看你的物理磁盘的本身性能，读取寻道时间，另一方面是你的数据分布需要调整，最后看看数据库表结构和SQL能不能调整拿去数据的方式和数量。

非常感谢。其实从await时间上只是一方面，另外一方面就是实际读写速度看起来并不是很高。这个问题也不好完全撇清问题所在。关于通过iostat磁盘的性能参数与存储的实际性能判断上面，有没有好的建议或者参考资料。感觉日常遇到类似问题，有点欠缺解决思路。

思路是这样的：

1. App关注的是什么？IOPS | MB/s | 响应时间 -> 如果你手边有参考值，那直接比对参考值。如果没有参考值，那只能亲身体验 + 估算应该达到的值。

2. i/o是App发出的，如果App本身不给力，那么再好的硬件也不会表现出很高的性能，因为App没有尽力去推I/O，所以了解自己的应用程序是第一步。

3. 性能问题需要分析整个I/O path，App -> server -> net -> storage，逐个分析，找到问题所在。

4. iostat完全可以参考：iostat(1) - Linux man page

5. 理性分析应有的性能，比如你这个case，你感觉读写应该是多高？如何判断出来的？有了量化，才能去判断是否达到了目标性能。

归档数据库？我看你平均IO大小avgrq-sz 还挺大的，有差不多150多个sector，差不多70KB的IO了，这个不是正常的OLTP的IO大小，是不是这段时间在跑备份作业？或者是什么报表在跑了。而且不单单是读，还有写入（rsec/s wsec/s 30352.00 11824.00，情况挺奇怪的。

还有你这个盘上还有没有存其他的类型的数据库文件，有事务日志有吗?16ms对于备份和报表已经不错了，OLTP的数据文件也可以了，10-20ms是可接受的范围。如果是事务日志，就显得有点慢了。

不知道您的这个数据库是使用的文件系统还是类似于ASM的存储空间。如果出现您说的那个情况是否是数据库数据文件分布的不均匀造成的呢？

现有磁盘是通过storage pool的方式，使用sata盘+FAST cache使用

SATA盘？什么规格？

前辈们演绎的相当精彩呀，比生硬的教科书强多了。

谢谢

楼主您的IOSTAT是什么系统下的版本哦。偶的HPUNIX下好像看不到哦

99.99%的utilization并不能说明性能有问题，只表示说存在局部热点，有优化的可能性。

我想楼主会不会认为如果其他几块盘都是50%，那就说明性能没问题了呢？呵呵。

我看楼主都是sda、sdb，都是用的分区盘吗？没有用LVM吗？可以尝试下LVM的stripe。

呵呵，看到sda、sdb、dm-*等就想到了是Linux呀，HPUX上没有这类设备名字的。