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

feng_yz

原帖由 shahand 于 2007-12-27 14:35 发表
你确定已经使用了dio/cio ？
为何还将maxperm设置这么高（90），这就是你free mem很少的原因吧

maxperm对于数据库系统来说，应该设置一个比较小的值，例如20，这样以来，我们就可以使文件系统的缓存数量减少。从而oracle系统能够使用更多的物理内存。

有用CIO.  我晓得IBM/oracle都说要把maxperm调体，可是SAP建议我们要调高，因为我们数据是使用文件系统，
以下是内存的一些输出值。
# svmon -G
               size      inuse       free        pin    virtual
memory     16777216   16773824       3392     911099    6281704
pg space   10485760      24772

               work       pers       clnt      lpage
pin          911099          0          0          0
in use      6281752          0   10492072          0
# vmstat -v
             16777216 memory pages
             16180987 lruable pages
                 3082 free pages
                    3 memory pools
               911162 pinned pages
                 80.1 maxpin percentage
                  3.0 minperm percentage
                 90.0 maxperm percentage
                 64.6 numperm percentage
             10467481 file pages
                  0.0 compressed percentage
                    0 compressed pages
                 64.7 numclient percentage
                 90.0 maxclient percentage
             10485143 client pages
                    0 remote pageouts scheduled
                    0 pending disk I/Os blocked with no pbuf
                    0 paging space I/Os blocked with no psbuf
                 2996 filesystem I/Os blocked with no fsbuf
                    0 client filesystem I/Os blocked with no fsbuf
              1278583 external pager filesystem I/Os blocked with no fsbuf

feng_yz

原帖由 biti_rainy 于 2007-12-27 15:33 发表


cat  /etc/tunables/nextboot

大多数情况下我们会设置类似如下几个参数：
        minperm%="5"
        maxperm% = "15"
        maxclient% = "10"
        strict_maxclient = "0"
        strict_maxperm = "0"
        v_pinshm = "1"

其中 strict_maxperm = "1"  表示 hard limit，也就是说只要设置了这个参数，fs cache 的使用就不会超过 maxperm 设定，如果这个为0，则表示 允许fs cache超过maxperm 设置，但在fs cache 介于 maxperm 和minperm之间的时候会有相关调度算法来决定是换 fs cache  页  还是  计算内存页。

在strict_maxperm的时候 fs cache倾向于尽量多的使用free memory，所以实际上依然会很大。 所以这个时候降低maxperm就降低性能的说法是不确切的。如果 v_pinshm = "1"  再配合 lock_sga=true ，则这部分原则上被 钉在物理内存中了不会参与页交换（除非另外一些特别情况产生） 。

所以lz的情况，db cache size 设置为32G的并且v_pinshm = "1"  再配合 lock_sga=true ，设置  strict_maxperm  为0 （为1 可能引起bug 致系统hang） ，那么 maxperm 设置为10  也就可以了。如果你还坚持设置为 80，那么建议同时跟上这个参数 lru_file_repage = "0"

lru_file_repage这个参数我们是设为0,贴一个sap note.

rollingpig

在OS strict_maxperm =0 , DB lock_sga=true的情况下，maxperm 社大设小似乎对整个性能影响不大

shahand

我还是坚持我的看法   增加db cache size同时应该调低maxperm

还要确保使用dio/cio

iops

1. I/O的负载承受度是固定的(32*10K*300G), 但是应用的性能需求是持续的增加,系统运行还没有缓慢到无法承受的程度, I/O wait 高是隐患.
2. 因为有些report要跑好几个月的资料，所以时间长点用户能接受:  是多长的时间,这个时间会随着数据量的增加, 而变长吗? 你的系统正式上线有多久的时间了?

feng_yz

原帖由 iops 于 2007-12-27 22:54 发表
1. I/O的负载承受度是固定的(32*10K*300G), 但是应用的性能需求是持续的增加,系统运行还没有缓慢到无法承受的程度, I/O wait 高是隐患.
2. 因为有些report要跑好几个月的资料，所以时间长点用户能接受:  是多长的时间,这个时间会随着数据量的增加, 而变长吗? 你的系统正式上线有多久的时间了?

多长时间不固定，有些是按季度来的。数据量增加速度肯定变慢了，再过几天，就是上线第3年的开始了。。

iops

当时间长到用户无法忍受的时间段,就是升级改造的开始. 所以应用负载的趋势预测分析,就成为一种专门的服务. 预测你的I/O可以承受多大的负载.

foxmile

原帖由 biti_rainy 于 2007-12-26 11:51 发表
一点建议：

share_pool_size 的 free虽然少但是parse却不多的，可以考虑控制在2G 以内

2:  SGA 大小  和你的oracle 进程数量有关，假定当前稳定数量是 N . 到底 oracle  process 每个消耗多少内存，sap 不知道是怎样的，比如正常数据库可能在5--6 MB/进程，但是 oracle  EBS 却几乎达到 20MB/进程  。如何看呢，这样

ps -e -o pid=PID -o 'vsz=VirtualMem(K)' -o rss='RealMem(K)' -o pcpu=%CPU -o args=command | sort -b +2 -n  |grep "LOCAL=NO"

这样将连接上来的server 进程的私有内存消耗排序列出来。你看看第二列，大体上平均值是多少。假定平均值是 M
则 SGA 大小可以这样控制：

SGA =  64G*80% -   N*M(MB)*150%/1024

这样假定你现在稳定有1000个进程，每个进程消耗10MB,那么就是
64*0.8 -  1000*10*1.5/1024, 大约可以设置到35G SGA 左右。 如果你使用的是文件系统，那么还可以适当降低SGA到30G 以内，但 sga 注意配合 VMO 调整v_pinshm同时使用 lock_sga = true   。

biti_rainy，每个进程消耗10m内存是估算还是确定。

performance

IO wait 这么高应该是不正常的. 一般应该在30%以下的


aix 参数SAP的建议是
minperm%         = 3
maxperm%         = 90
maxclient%       = 90
lru_file_repage  = 0
strict_maxclient = 1
strict_maxperm   = 0
processors * 120 pages = -f(minfree)
processors * 128 pages = -F(maxfree)

db cache size 建议最好分成两个. 把命中率特别低的table搞在一起.省得搞坏buffer里有用的数据.

victor1010

顶！
好顶！
学习了！