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

shahand

是否是raid5？

shahand

确认 aio 开启。

feng_yz

存储是RAID5,没有使用条带技术,没有swap,使用的是文件系统,aio已经开了。

feng_yz

原帖由 biti_rainy 于 2007-12-26 11:52 发表
由于 SAP 的应用要调整sql 是异常的困难，加个索引什么的还可以考虑，所以扩大 db  cache  size 是最直接有效的办法。
当然，如果有的表只是在一些report中才会用到不太关心命中率 但表又比较大，为了不影响其他表的命中率，可以给这类表单独开一个  recycle  pool，给个三两个g 内存。

谢谢大师的建议.
确实调整SAP的应用想当麻烦。 但是有一个现象， 我在年初时db_cache_size是6G,后来改为12G,可是命中率还是一样的。
关于给表单独开一个recycle  pool,具体如何操作, 是否对应用有影响,可否麻烦给一些资料供参考。
不胜感激!!

rollingpig

建议收集几次v$segment_statistics，找出physical read比较集中的segment……

kiddwyl

关于iowait过高的情况，我这里有点经验之谈，拿出来给大家参考：）
系统的瓶颈在于I/O，而I/O的瓶颈源于不合理的磁盘配置，以及较低的物理内存(包括两个数据库实例竞争)导致过量的swap空间的使用而致。

基本建议：
1. 如果不更改现在的硬盘布置和应用部署，增加该机器的实际物理内存是最直接和有效的手段，建议增加物理内存到4Gb或更大；
2．在内存较为紧张的情况下，为了减小系统swap负载，建议更改磁盘部署成裸设备；并调整磁盘的RAID1的部署为RAID5， 在分配lv时采用stripe技术；
如果采用裸设备，建议把数据库配置成RAC模式，可以分开当前的两个应用，而且也起到容错的功能；由现在的Failover更改到RAC而无须增加硬件成本；
    3．调整部分磁盘、内存、swap的配置参数可以在一定程度上优化系统；

这是一个案例分析后的结论建议：）

feng_yz

原帖由 kiddwyl 于 2007-12-26 15:46 发表
关于iowait过高的情况，我这里有点经验之谈，拿出来给大家参考：）
系统的瓶颈在于I/O，而I/O的瓶颈源于不合理的磁盘配置，以及较低的物理内存(包括两个数据库实例竞争)导致过量的swap空间的使用而致。

基本建议：
1. 如果不更改现在的硬盘布置和应用部署，增加该机器的实际物理内存是最直接和有效的手段，建议增加物理内存到4Gb或更大；
2．在内存较为紧张的情况下，为了减小系统swap负载，建议更改磁盘部署成裸设备；并调整磁盘的RAID1的部署为RAID5， 在分配lv时采用stripe技术；
如果采用裸设备，建议把数据库配置成RAC模式，可以分开当前的两个应用，而且也起到容错的功能；由现在的Failover更改到RAC而无须增加硬件成本；
    3．调整部分磁盘、内存、swap的配置参数可以在一定程度上优化系统；

这是一个案例分析后的结论建议：）

好象你列举的这些不太适合我，我已经用RAID5+64G RAM ..谢谢。

李迪

RAID5，应该换换把

  以前在公司是6块盘做RAID10，系统一直有一定的IO问题，有些IO问题不是调语句就能解决的，为了解决这个问题，口舌之争是少不了的，后来把6块盘的RAID10扩成12块的RAID10，IO问题就解决了

kiddwyl

原帖由 feng_yz 于 2007-12-26 15:54 发表

好象你列举的这些不太适合我，我已经用RAID5+64G RAM ..谢谢。

那我觉得你应该从SQL本身出发去寻找原因了，通过大批量的SP压力测试，来检查你觉得可疑的SQL语句，并察看v$session_wait队列等步骤

举例：

查看一下SQL到底在做些什么事情，查询SQL如下所示：

select sql_text,spid,b.program,process
    from v$sqlarea a,
             v$session b,
             v$process d
    where a.address = b.sql_address
         and a.hash_value = b.sql_hash_value
         and b.paddr = d.addr
         and d.spid in (进程ID);

  进程ID我们可以通过TOP命令查看到

得出有一条SQL语句在运行中竟然耗费了将近1.5小时的时间，并且IOWAIT过高
所以基本上可以断定是这条SQL语句造成的，所以我们可以通过以下2个方面来进行处理：

首先我们通过查看v$session_wait来查看队列，SQL如下：

SQL>select sid,event,p1,p1text from v$session_wait

通过查看，大多都属于latch free状态，那么我们就查一下是什么原因产生了latch free状态，SQL如下：

SQL>select spid from v$process where addr in (select paddr from v$session where sid in(.........));

rollingpig

statspack report都有了，无需在话时间去通过v$session_wait找Top SQL了