oracle中文博客,[转载Oracle官方中文博客]关于RunQ过高引起的latch等待问题

最近一个客户新上线系统做压力测试发现负载一直上不去，cpu 只有20%左右，

遇到大量latch: ges resource hash list等待事件，客户怀疑数据库存在瓶颈，

导致测试结果无法达到他们性能要求，要求进行诊断。我们先看一下AWR 情况：

Top 10 Foreground Events by Total Wait Time

vent Waits Total Wait Time (sec) Wait Avg(ms) % DB time

latch: ges resource hash list 723,722 76.6K 105.86 16.8    <<<16.8%

DB CPU 31K 6.8                                             <<<6.8

latch free 207,653 22.5K 108.33 4.9 Other                  <<<<<

上述top10可以看到，的确latch: ges resource hash list等待占用了大量的

DB time，平均达到了105ms，这个是非常差的一个指标，因为latch是cpu上的

操作，连普通磁盘操作一般才几毫秒，所以的确像是DB端遇到了问题，根据

这个等待事件搜索MOS系统，的确有一个已知bug，但是进一步check用户的Opatch，

居然这个bug已经打上了，难道补丁fix不完整？我们暂时不能下这个结论，

看看AWR的负载情况：

Snap Id Snap Time Sessions Cursors/Session Instances

Begin Snap: 462 03-Oct-16 23:15:24 1166 11.4 2  <<1166

End Snap: 463 03-Oct-16 23:24:39 1149 11.7 2    <<1149

Host Name Platform CPUs Cores Sockets Memory (GB)

nsdb3 AIX-Based Systems (64-bit) 512 256   945 <

Buffer Cache: 214,528M 214,528M Std Block Size: 8K   <<<214G

Shared Pool Size:51,200M 51,200M Log Buffer: 1,565,292K<<<51G

上面看出新系统配置非常高，512颗cpu，内存接近1T，给DB使用也

足有250G多G可是session 数量只有1000+，笔者见过配置比这低得多，

但是session轻松超过7000+，所以的确压力是没上来，我们在看一下

top10，发现排名第二个的居然是DB CPU，这说明等待CPU也花费了很

长时间，这个应该是cpu不够的征兆，但是客户说cpu利用率才20%，

我们看一下vmstat输出:

kthr    memory                           faults        cpu

----- ----------- ------------------------ ------------ -----------

r  b   avm   fre          cy  in   sy  cs us sy id wa

40  0 151956625 91351897 86916 672284 227787 14  3 82  1 <

19  0 151956150 91352222 81535 324016 207307 13  2 84  1 <

25  0 151954274 91353963 82828 329847 206551 13  2 84  1 <

的确idle平均超过80%，但是仔细看RunQ居然达到40，Runq意思是有多少 进程处于可运行队列中，正在等待cpu调度，剩余那么多cpu资源居然还有大 量进程在排队等待运行，这是非常奇怪的现象，再次查看mpstat输出: cpu  min  maj  mpc  int   cs  ics   rq  mig lpa sysc us sy wa id   pc  0  236    0    0  440  828   12    1   45 100 2539 52  9  5 34 0.38   <<<