IBM590+DS8100+SAP 有超高的I/O Wait

feng_yz

原帖由 BTxigua 于 2007-12-27 09:07 发表




小io响应在2ms， 整体iops 有1w9 以上。
请教一下，这两个是怎么看出来的？

请参考这里：http://www.itpub.net/thread-916896-1-3.html

anlinew

原帖由 feng_yz 于 2007-12-27 09:25 发表

确实是这样的，Module: Z*** 这些程序都是我们自己开发的，性能较差，有可优化的空间。
因为有些report要跑好几个月的资料，所以时间长点用户能接受，整体看系统并不慢。

tuning 掉这些sql，iowait也就随之解决了。。。

Fenng

原帖由 rollingpig 于 2007-12-27 09:14 发表
IOPS 看起来很高的原因在于 OS file system cache.

可以这么看：

DB Logical read  

||
\/

(Not found in DB cache) ==> 反映为 db hit ratio ,跟db_cache_size相关,本例为12G
DB Physical read ==> 本例中Random IO反应时间（db file sequntial read average wait time )为2ms

||
\/

(Not found in OS cache, or use raw device , direct IO ) ==> 反映为file system cache hit ratio, 跟用作file cache的OS memory相关，本例中高达64G-18G(SGA)-4G(PGA)-2G(系统开销)-0G(看到的free memory)=40G
Storage IO

||
\/

(Not found in Storage cache) ==>反映为 Storage cache hit ratio, 跟Storage cache size有关
Disk IO

||
\/

(Not found in Disk cache)
磁道IO ==> 这个Random IO反应时间通常为大约 7ms (Average seek time + latency time)



所以，从DB看到的接近1W多 IOPS，并没有真正反映到底层Disks上，而是很大一部分被“file system cache hit ”给吃掉了。
这也是为什么很多statspack显示的Random IO反应时间（db file sequntial read average wait time ) 会很明显低于disk io 反应时间 (Average seek time + latency time).

用文件系统的话, 要另当别论了

anlinew

原帖由 rollingpig 于 2007-12-27 09:14 发表
IOPS 看起来很高的原因在于 OS file system cache.

可以这么看：

DB Logical read  

||
\/

(Not found in DB cache) ==> 反映为 db hit ratio ,跟db_cache_size相关,本例为12G
DB Physical read ==> 本例中Random IO反应时间（db file sequntial read average wait time )为2ms

||
\/

(Not found in OS cache, or use raw device , direct IO ) ==> 反映为file system cache hit ratio, 跟用作file cache的OS memory相关，本例中高达64G-18G(SGA)-4G(PGA)-2G(系统开销)-0G(看到的free memory)=40G
Storage IO

||
\/

(Not found in Storage cache) ==>反映为 Storage cache hit ratio, 跟Storage cache size有关
Disk IO

||
\/

(Not found in Disk cache)
磁道IO ==> 这个Random IO反应时间通常为大约 7ms (Average seek time + latency time)



所以，从DB看到的接近1W多 IOPS，并没有真正反映到底层Disks上，而是很大一部分被“file system cache hit ”给吃掉了。
这也是为什么很多statspack显示的Random IO反应时间（db file sequntial read average wait time ) 会很明显低于disk io 反应时间 (Average seek time + latency time).

statspark里记录的是逻辑读写，这里的响应时间能说明的只是系统目前的IO还不算糟
要说明硬件能力如何，还真不一定
这个帖子不是我给引到硬件能力上的，

[ 本帖最后由 anlinew 于 2007-12-27 10:31 编辑 ]

Tomac

精華貼輪留名.
這么強的機器, 還在擔心IO. 何必做raid5, 換RAID10沒錢嗎.

liangmin11

顶楼上的!  存储的空间, 硬件的能力看上去都有不小的预留!  为什么不做1+0呢, 提高IO能力是硬件最需要做的吧?

feng_yz

原帖由 liangmin11 于 2007-12-27 11:24 发表
顶楼上的!  存储的空间, 硬件的能力看上去都有不小的预留!  为什么不做1+0呢, 提高IO能力是硬件最需要做的吧?

前期规划有问题,现在是7*24,要改成1+0谈何容易.

biti_rainy

原帖由 liangmin11 于 2007-12-27 11:24 发表
顶楼上的!  存储的空间, 硬件的能力看上去都有不小的预留!  为什么不做1+0呢, 提高IO能力是硬件最需要做的吧?

读写比例非常大，所以做raid5 和 raid10 对他这个系统io影响应该不大的(更何况目前还没出现io 瓶颈)。分析问题要具体例子具体分析，而不是把一些教条不加考虑的乱套。

gengyonghui

无非也就是一些大sql,能调整当然好，也许调也没法调，人家就是这么写的。

Tomac

沒有出現IO瓶頸,只是在擔心IO瓶頸.