客户的系统进行压力测试时发现CPU压力非常大，正常情况下CPU负载在30-40%，而峰值期间CPU基本上100%，以至于事务无法处理完成，甚至无法登陆。
经过客户的描述，这个压力测试实际上压力应该不大，仅仅设置了100个客户端的并发，而且单个客户端整个功能模块完成实际上仅需要25秒钟，但并发一多，CPU负载就非常高，以至于单个功能模块完成时间被延长至几百秒。
到客户现场，在操作系统级察看，CPU大量消耗在user上，io的CPU等待很少，确定CPU是消耗在应用层面。
[oracle@localhost ~]$ sar -u 3 50 Linux 2.6.18-92.el5 (localhost.localdomain) 2009年06月15日 _x86_64_ (8 CPU)
14时56分50秒 CPU %user %nice %system %iowait %steal %idle 14时56分53秒 all 93.29 0.00 1.08 0.00 0.00 5.62 14时56分56秒 all 90.54 0.00 1.33 0.00 0.00 8.12 14时56分59秒 all 93.00 0.00 1.08 0.00 0.00 5.93 14时57分02秒 all 92.34 0.00 0.92 0.00 0.00 6.75 14时57分05秒 all 93.25 0.00 0.87 0.00 0.00 5.88 14时57分08秒 all 92.06 0.00 1.02 0.00 0.00 6.92 14时57分11秒 all 91.95 0.00 0.87 0.00 0.00 7.18 14时57分14秒 all 92.71 0.00 0.92 0.00 0.00 6.38 14时57分17秒 all 92.19 0.00 0.87 0.00 0.00 6.94 14时57分20秒 all 94.96 0.00 0.79 0.00 0.00 4.25 14时57分23秒 all 92.91 0.00 0.83 0.00 0.00 6.26 14时57分26秒 all 92.06 0.00 0.70 0.00 0.00 7.24 |
由于客户描述的情况中并发量与CPU消耗有直接关系，因此怀疑有应用级并发的竞争，于是收集了一下Statspack报告，在命中率方面：
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: | 99.98 | Redo NoWait %: | 99.98 |
Buffer Hit %: | 100.00 | In-memory Sort %: | 100.00 |
Library Hit %: | 74.95 | Soft Parse %: | 72.85 |
Execute to Parse %: | 0.27 | Latch Hit %: | 97.18 |
Parse CPU to Parse Elapsd %: | 9.47 | % Non-Parse CPU: | 7.65 |
库高速缓存的命中率很低，硬解析很高，而硬解析与CPU消耗有直接关系。
在等待事件方面：
Top 5 Timed Events
Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
latch: library cache | 5,679,771 | 363,979 | 64 | 86.1 | Concurrency |
CPU time |
| 41,658 |
| 9.9 |
|
latch: shared pool | 1,908,510 | 6,061 | 3 | 1.4 | Concurrency |
latch free | 192,585 | 5,334 | 28 | 1.3 | Other |
latch: cache buffers chains | 19,228 | 823 | 43 | .2 | Concurrency |
很明显，主要等待都集中在与库高速缓存相关的Latch竞争上，库高速缓存是主要的性能问题，而且硬解析也主要在消耗CPU，看来性能瓶颈已经表现出来了，通过下面会话级的直接查询，也发现在大量会话中同时都存在着latch: library cache 竞争：
select event from v$session_wait where event not in ('SQL*Net message from client','rdbms ipc message')
EVENT ---------------------------------------------------------------- SQL*Net message to client latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: shared pool latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache latch: library cache 。。。。。。 smon timer pmon timer |
目前客户的共享池有544M，而在程序运行过程中共享池的剩余空间还有59M，同时从报告中的共享池大小建议上看，对于目前的应用来说，共享池只需要400多M就足够，因此造成库高速缓存命中率低，硬解析高，CPU大量消耗的主要原因很可能是SQL代码没有共享。
Shared Pool Size(M) | SP Size Factr | Est LC Size (M) | Est LC Mem Obj | Est LC Time Saved (s) | Est LC Time Saved Factr | Est LC Load Time (s) | Est LC Load Time Factr | Est LC Mem Obj Hits |
416 | 0.76 | 67 | 7,820 | 3,652 | 0.98 | 466,989 | 1.00 | 3,518,320 |
480 | 0.88 | 130 | 15,164 | 3,710 | 1.00 | 466,931 | 1.00 来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/20034375/viewspace-1023179/，如需转载，请注明出处，否则将追究法律责任。
上一篇：
DBMS_SPACE包的使用（2）
请登录后发表评论
登录
全部评论
<%=items[i].createtime%>
<%=items[i].content%> <%if(items[i].items.items.length) { %>
<%for(var j=0;j
<%}%> <%}%>
<%=items[i].items.items[j].createtime%>
回复
<%=items[i].items.items[j].username%> 回复 <%=items[i].items.items[j].tousername%>： <%=items[i].items.items[j].content%>
还有<%=items[i].items.total-5%>条评论
) data-count=1 data-flag=true>点击查看
<%}%>
北京盛拓优讯信息技术有限公司. 版权所有 京ICP备09055130号-4 北京市公安局海淀分局网监中心备案编号：11010802021510 广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员 |
转载于:http://blog.itpub.net/20034375/viewspace-1023179/
977
到【灌水乐园】发言
