最近一个客户新上线系统做压力测试发现负载一直上不去，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 NamePlatformcpuscoresSocketsMemory (GB)
nsdb3AIX-Based Systems (64-bit)512256 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层面的监控数据来进一步分析原因。