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

bluemoon0083

好贴就要学习

anlinew

原帖由 feng_yz 于 2007-12-26 22:21 发表

这些参数是SAP 推荐要设置的，具体的原因要参考SAP的相关note.

OLTP系统？从report看起来又不像

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

feng_yz

原帖由 anlinew 于 2007-12-26 23:27 发表

OLTP系统？从report看起来又不像

是OLTP ....

anlinew

原帖由 feng_yz 于 2007-12-27 08:17 发表

是OLTP ....

top sql里很多sql都不是sap基本产品的吧，也不像是OLTP业务

比如：
    2,418,789            1    2,418,789.0    1.7    41.61   1057.87 1813408425
Module: ZIEIP0011
SELECT T_01 . "MATNR" , T_01 . "WERKS" , T_01 . "BWART" , T_01 .
"LGORT" , T_01 . "BUKRS" , T_01 . "MEINS" , T_01 . "MENGE" , T_
01 . "SHKZG" , T_02 . "MTART" , T_00 . "MBLNR" , T_00 . "MJAHR"
, T_00 . "BUDAT" , T_01 . "CHARG" FROM "MKPF" T_00 , "MSEG" T_01
, "MARA" T_02 WHERE ( T_01 . "MANDT" = :A0 AND T_00 . "MBLNR" =

9,034,144           16      564,634.0    6.2   238.91   1854.79 4065876404
Module: ZMMRT0024
SELECT T_00 . "MATNR" , T_00 . "LGORT" , T_00 . "WERKS" , T_00 .
"LABST" FROM "MARD" T_00 , "MARA" T_01 WHERE ( T_01 . "MANDT" =
:A0 AND T_00 . "MATNR" = T_01 . "MATNR" ) AND T_00 . "MANDT" =
:A1 AND T_00 . "WERKS" = :A2 AND T_00 . "LGORT" = :A3

很奇怪你的系统不缓慢，从report看很多业务都是1分钟甚至10几分钟才能执行完的

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

biti_rainy

这种通用的系统，要想从 sql 上下工夫可行性很小，比如 SAP \ oracle EBS \ people soft \ IBM RPM 等等  具备通用性由的系统，包括 用友和金碟我想对于客户来说情况应该差不多。

有时候一个用户登陆或者点击操作，要执行上百条sql…… 因为很多东西都是配置好的，有的界面上按钮都是根据配置生成出来的…… 所以tuning sql的可行性比较小。这种系统往往对硬件资源的要求非常高，不过整体上来说，系统在硬件上的投入也不过是比较小比例的一块。

BTxigua

原帖由 biti_rainy 于 2007-12-26 09:22 发表
你存储有多少 cache 多少磁盘？  cache 命中率太低，是不是应用和db 在一台机器上跑的，db_cache_size 是否可以增加？

看 小io响应在2ms， 整体iops 有1w9 以上，看起来算是不错的响应了。
前台io wait 显示高未必是严重异常，有可能说明cpu 除了等io外并没有其他事情好做。

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

rollingpig

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).

原帖由 Fenng 于 2007-12-26 21:12 发表
这么几块 10K 转的硬盘能跑到 将近 20000 个 IOPS , 已经发挥到刘翔奥运会跨栏的表现水平了

不知道平均负载如何

这 DB 主要是                Transactions:                  5.70 太小了, 否则的话, 事务多一点, 这么大的 IO 早翘了

anlinew

原帖由 biti_rainy 于 2007-12-27 09:06 发表
这种通用的系统，要想从 sql 上下工夫可行性很小，比如 SAP \ oracle EBS \ people soft \ IBM RPM 等等  具备通用性由的系统，包括 用友和金碟我想对于客户来说情况应该差不多。

有时候一个用户登陆或者点击操作，要执行上百条sql…… 因为很多东西都是配置好的，有的界面上按钮都是根据配置生成出来的…… 所以tuning sql的可行性比较小。这种系统往往对硬件资源的要求非常高，不过整体上来说，系统在硬件上的投入也不过是比较小比例的一块。

topsql 里大多数sql可能都不是标准SAP的，如果是，也是必须要tuning的

anlinew

原帖由 anlinew 于 2007-12-26 21:00 发表
SAP这样的系统不知道处于什么考虑要这么设置参数：
_optim_peek_user_binds        FALSE
_optimizer_join_sel_sanity_ch TRUE
_optimizer_or_expansion       DEPTH
_push_join_predicate          FALSE
_sort_elimination_cost_ratio  10
db_file_multiblock_read_count 8
hash_join_enabled             FALSE
optimizer_index_cost_adj      10

还不如干脆就RBO呢

这样的设置会严重倾向于使用index 以及NLJ，比RBO更甚，对于纯OLTP系统当然无所谓
一旦系统里有一些需要访问较多数据的查询，如report里的top sql ，其直接的后果可能就是大量的db file sequential read wait产生

feng_yz

原帖由 anlinew 于 2007-12-27 09:15 发表

topsql 里大多数sql可能都不是标准SAP的，如果是，也是必须要tuning的

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