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

原文网址:

https://blogs.oracle.com/Database4CN/entry/%E5%85%B3%E4%BA%8Erunq%E8%BF%87%E9%AB%98%E5%BC%95%E8%B5%B7%E7%9A%84latch%E7%AD%89%E5%BE%85%E9%97%AE%E9%A2%98

关于RunQ过高引起的latch等待问题

By Mao Bin-Oracle on 十一月 20, 2016

最近一个客户新上线系统做压力测试发现负载一直上不去，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 <<cpu=512

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 <<idle=82
19  0 151956150 91352222 81535 324016 207307 13  2 84  1 <<idle=84
25  0 151954274 91353963 82828 329847 206551 13  2 84  1 <<idle=84

的确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   <<<<工作cpu
 1    0    0    0  194    0    0    0    1 100    0  0  1  0 99 0.21
 2    0    0    0  189    0    0    0    1 100    0  0  1  0 99 0.21
 3    0    0    0  191    0    0    0    1 100    0  0  1  0 99 0.21
 4  150    0    0  318  771   62    1   57 100 7003 37 15  1 46 0.36  <<<<工作cpu
 5    0    0    0  191    0    0    0    1 100    0  0  1  0 99 0.22
 6    0    0    0  191    0    0    0    1 100    0  0  1  0 99 0.22
 7    0    0    0  188    0    0    0    1 100    0  0  1  0 99 0.21 
 ......
 从上面可以看出列出8颗cpu只有2个在干活，所以整个系统只有1/4 cpu在干活,最终定位是OS 问题 。从上面的问题分析来看，对于latch等待过高的场景除了怀疑已知bug之外最有
可能的是CPU资源不足，若是idle很空闲，可能是OS层面的问题，这次Runq就给了我们
一个很好的线索，所以一定要结合OS层面的监控数据来进一步分析原因。