很高的 r 和 load avg 值

funnyok

我的db server的vmstat有很高的 r 和 load avg 值。
r高的同时sy也很高。
在一般的统计上(statspack and v$)，竞争并不时最主要的因素。不过从感觉讲，我认为是有enqueue和latch的竞争。

funnyok

[php]
tail -f vmstat.log
2006/07/20 18:48:13 procs                      memory      swap          io     
system         cpu
2006/07/20 18:48:13  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
2006/07/20 18:48:13  1  1 341388  16276  19496 2597860    0    0  8080   466 1777  3369  6  4 36 54
2006/07/20 18:48:24 67 10 341388  16492  19684 2597468    0    0   722    98  689  883  2 86  8  4
2006/07/20 18:48:34  1  3 341352  16408  19868 2596716    0    0  2675   530 1435  2703  3  1 62 34
2006/07/20 18:48:44  0  0 341332  16392  19640 2596108   20    0  3764   426 1691  2960  2  1 70 27
2006/07/20 18:48:54  0  1 341220  16240  19180 2596792    1    0  2991   338 1639  2918  3  1 65 31
2006/07/20 18:49:04  0  0 341164  17924  19520 2595208    8    0  2878   282 1240  2587  7  3 64 26
2006/07/20 18:49:15 72  5 341164  17824  19532 2595300    0    0   175    38  471  663  0 84 15  1

[/php]

funnyok

[php]
top

18:51:33  up 3 days, 14:10,  8 users,  load average: 5.44, 18.87, 20.99
460 processes: 459 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total    1.6%    0.0%    0.7%   0.0%     0.6%   19.3%   77.5%
           cpu00    0.3%    0.0%    0.3%   0.0%     5.3%    0.5%   93.2%
           cpu01    0.7%    0.0%    0.3%   0.0%     0.0%    0.3%   98.4%
           cpu02    5.3%    0.0%    1.1%   0.0%     0.0%   43.1%   50.2%
           cpu03    1.1%    0.0%    0.1%   0.1%     0.0%   48.1%   50.2%
           cpu04    1.5%    0.0%    2.3%   0.0%     0.0%    9.3%   86.6%
           cpu05    0.7%    0.0%    0.0%   0.1%     0.0%    9.7%   89.2%
           cpu06    0.9%    0.0%    0.9%   0.0%     0.0%   21.4%   76.5%
           cpu07    2.1%    0.0%    0.1%   0.0%     0.1%   21.8%   75.5%
Mem:  3857224k av, 3841116k used,   16108k free,       0k shrd,   17132k buff
                   2472180k actv,  471788k in_d,   59444k in_c
Swap: 8385792k av,  340460k used, 8045332k free                 2602328k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
24430 oracle    15   0  785M 784M  781M S     0.5 20.8   1:03   2 oracle
24272 oracle    15   0  510M 509M  507M S     0.2 13.5   0:44   6 oracle
24498 oracle    15   0  587M 586M  584M S     0.2 15.5   1:11   3 oracle
6190 root      15   0 15732 1308   964 S     0.1  0.0   7:50   2 X
24298 oracle    15   0  702M 699M  696M S     0.1 18.5   1:24   1 oracle
29023 ora_nttk  15   0  1292 1292   684 S     0.1  0.0   5:15   6 top
  346 oracle    15   0  1292 1292   688 S     0.1  0.0   3:34   4 top
    1 root      15   0   492  460   432 S     0.0  0.0   3:46   6 init

[/php]

funnyok

问题有两个：
1 转瞬即逝
本来v$session_wait的p...可以定位一些东西。不过v$session_wait转瞬即去。我的run queue也是转瞬即去。
2 其他问题突出
系统是web oltp， io本来就不足， commit过多， 一小部分sql没有bind，一般的report上这些问题过于突出，以至于真正的问题被隐藏了起来。statspack设到5分间隔了，还是sequencal read之类是top 5。
但是从经验来讲这些都不到系统down的程度。之所以down，一定是某些东西成为了并发的瓶颈。而且一旦发生，就会成指数性恶化。

trace, statspack level 10, 1秒一次v$session_wait之类或许可行，但是系统几乎承受不了这样的诊断了。

大家有没有什么好的诊断方法？

bulkaunt

24430 oracle    15   0  785M 784M  781M S     0.5 20.8   1:03   2 oracle
24272 oracle    15   0  510M 509M  507M S     0.2 13.5   0:44   6 oracle
24498 oracle    15   0  587M 586M  584M S     0.2 15.5   1:11   3 oracle
24298 oracle    15   0  702M 699M  696M S     0.1 18.5   1:24   1 oracle

看下这几个东西里面跑的东西，这么耗资源。这时候再多几个ORACLE进程，你的R 和SY就又上升了

bulkaunt

1 转瞬即逝
本来v$session_wait的p...可以定位一些东西。不过v$session_wait转瞬即去。我的run queue也是转瞬即去。

但是看你的TOP

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
24430 oracle    15   0  785M 784M  781M S     0.5 20.8   1:03   2 oracle
24272 oracle    15   0  510M 509M  507M S     0.2 13.5   0:44   6 oracle
24498 oracle    15   0  587M 586M  584M S     0.2 15.5   1:11   3 oracle

执行时间这么长，怎么可能会转瞬即去呢。

要是我就开两个SCRT，一个执行TOP，另一个开个SESSION连接倒数据库，把要查询的语句准备好，看到SIZE  和RSS 占用几百兆的，立马记下PID，执行查询，马上就可以看到这个进程到底在干什么。

funnyok

谢谢你的回答。
我试图抓过，不过我们的application 是web的oltp，用connection pool。
所以，size和rss并不能说明现在的query使用了大量资源。
的确application中有少数处理使用大量资源，
但是那些处理都经过限制和优化，至少不会大量并发。
如果是那些处理的问题，那么vmstat将会在wa和us上表现出来。
sy的数值应该是与os service的过量使用有关。
比如semaphone或者process switch之类。

另外，application里有一个排他处理非常成问题。
虽然没有确切的证据，但是如果把这个功能去掉，
系统即便负荷很高也不会down。

这个机能是：
-- 同一条记录不能让多个用户同时看。
实现是用一个当前阅览记录表：
如果里面没有别的用户相应记录的话，就可以看。
如果里面有别的用户相应记录的话，就不可看。

这个做法本身有问题，应该用别的方法
但是application不能随便改。

现在的这个做法的话，这张小表倒是几乎作完操作立即commit;。
只不过delete的时候好像经常容易出现等待。
曾试图改成不加pk的hash partition但是也没有什么效果。

funnyok

ding

funnyok

ding!!!