小io响应在2ms， 整体iops 有1w9 以上，看起来算是不错的响应了。

bluemoon0083

响应时间快的未必吞吐量就大

anlinew

原帖由 biti_rainy 于 2007-12-26 21:20 发表



响应时间+IOPS 就说明了系统的当前io状况啊，你还要什么才能说明？


响应时间是一个很重要的衡量指标，如果你要说存储的io能力，基本可以定义为，响应时间在 10ms 左右能达到的最大iops 能力，是系统io能力的一个最重要指标。  但生产系统大多达不到最大压力…… 那就只能说明io 子系统是正常的。


不知道你要看什么情况，非要看到io响应在20ms 以上才算数？  那不过是说明io将有问题了。

这个跟我说的是一个意思 wait 情况代表busy情况，能说明io状况

分歧在于IO能力的说法上，“响应时间在 10ms 左右能达到的最大iops 能力，是系统io能力的一个最重要指标”，如果是指瞬时值的话，这种说法我同意，可惜STATSPACK不是，又无法确定report期间始终都是这个状态

这个我赞成cc59的说法avg wait time + iops只有在一些特殊情况下才能说明IO能力

一个实际性能比当前设备好上10倍的设备得出现在的STATSPACK指标一点儿也没问题吧

[ 本帖最后由 anlinew 于 2007-12-26 22:52 编辑 ]

biti_rainy

1:衡量系统io能力，我们也是关注的高峰期一段时间内稳定运行的状况，没人会过多关注 瞬时 这个东西，瞬时是不可靠的，如果瞬时命中在存储cache 有什么意义。

2:问题是，人家给出 statspack 的根本目的不是为了让你告诉他  他的系统的io 能力。也没人说 这些指标能 说明io 系统的能力上限是多少。也没有人 问  系统的io能力是多少。系统的io能力不是看出来的，只是下限通常可以根据 磁盘转速和磁盘数量 就算出来，至于上限，影响的因素太多了。



3: 回过头来，没有人说根据这些能说明这个系统的io能力到底是多大，不同系统之间这些值往往不具备横向比较的可行性。 所以一开始你的 发问 实际上没有着力点。 这也是阐述了这么多 我们其实还是在自说自话。

anlinew

原帖由 biti_rainy 于 2007-12-26 23:06 发表
1:衡量系统io能力，我们也是关注的高峰期一段时间内稳定运行的状况，没人会过多关注 瞬时 这个东西，瞬时是不可靠的，如果瞬时命中在存储cache 有什么意义。

2:问题是，人家给出 statspack 的根本目的不是为了让你告诉他  他的系统的io 能力。也没人说 这些指标能 说明io 系统的能力上限是多少。也没有人 问  系统的io能力是多少。系统的io能力不是看出来的，只是下限通常可以根据 磁盘转速和磁盘数量 就算出来，至于上限，影响的因素太多了。



3: 回过头来，没有人说根据这些能说明这个系统的io能力到底是多大，不同系统之间这些值往往不具备横向比较的可行性。 所以一开始你的 发问 实际上没有着力点。 这也是阐述了这么多 我们其实还是在自说自话。

1、2 不说了，我明白你的意思，的确没说到一块儿去。。。。

3、我刚才也看了，是我把话题给引导IO能力上去了，我理解错了楼主问这个问题的目的了

rollingpig

简单来说，如果一个database在peak time显示出来的db file sequential/scattered read average wait time的指标明显低于7 ms, 那么，我们不应该把焦点集中在Storage 上。虽然这个指标不一定说明Storage 性能很好，但是至少表明系统的瓶颈并不在Storage 上1，改善Storage 性能未必能获得很高回报。
反之，如果一个database在peak time显示出来的db file sequential/scattered read average wait time的指标明显高于10 ms,我们可能需要关注Storage的性能是否存在瓶颈，当然，同时也可以从降低Total IO的角度去处理。

dpjude

原帖由 rollingpig 于 2007-12-27 09:48 发表
简单来说，如果一个database在peak time显示出来的db file sequential/scattered read average wait time的指标明显低于7 ms, 那么，我们不应该把焦点集中在Storage 上。虽然这个指标不一定说明Storage 性能很好，但是至少表明系统的瓶颈并不在Storage 上1，改善Storage 性能未必能获得很高回报。
反之，如果一个database在peak time显示出来的db file sequential/scattered read average wait time的指标明显高于10 ms,我们可能需要关注Storage的性能是否存在瓶颈，当然，同时也可以从降低Total IO的角度去处理。

olivenan

HP-UNIX 11.23  RS6600
Oracle 10203,RAC架构
存储EVA4000
根据大师的指点，我查看了自己的系统，发现
db file sequential read    平均等待时间是     7 ms

Physical reads:非常小，据此是不是可以初步判断EVA4000的性能比较差。

[ 本帖最后由 olivenan 于 2007-12-27 11:26 编辑 ]

biti_rainy

原帖由 olivenan 于 2007-12-27 11:24 发表
HP-UNIX 11.23  RS6600
Oracle 10203,RAC架构
存储EVA4000
根据大师的指点，我查看了自己的系统，发现
db file sequential read    平均等待时间是     7 ms

Physical reads:非常小，据此是不是可以初步判断EVA4000的性能比较差。

不是，响应时间在10ms 以内都是正常的！ 这个主要跟 存储的cache命中率有关系，如果不命中cache走磁盘，基本都这样的。

olivenan

原帖由 biti_rainy 于 2007-12-27 11:52 发表


不是，响应时间在10ms 以内都是正常的！ 这个主要跟 存储的cache命中率有关系，如果不命中cache走磁盘，基本都这样的。

多谢，10ms这个临界值是怎么得来的？是经验，还是Oracle提供的数据？
还有对于现在流行的存储 iops值一般是多少？
就像您刚才提到的 8100 1W9说明该存储性能不错。
对于不了解这些的  Physical reads:             19,266.92 只是一个数值，
很难跟存储联系到一起？您给大家有什么建议？
谢谢

rollingpig

一个random IO的理论时间是：
7ms =  4-5ms(磁盘平均寻道时间）+ 2ms (传输时间) + 一些其它的消耗
如果不考虑file system cache hit(raw device/direct IO)  以及storage cache hit , 同时没有磁盘竞争，那么，db file sequntial read的时间就会是 7ms左右.

而由于file system cache hit和storage cache hit的情况下，没有磁盘竞争的系统db file sequntial read 会小于 7ms
如果有磁盘竞争，而且竞争产生的延迟> file system cache hit和storage cache hit的好处，就会大于7ms .
10ms 可以说是一个经验值，就是磁盘竞争产生的延迟比较高了