ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 熊猫大侠一次性能诊断优化十一问

熊猫大侠一次性能诊断优化十一问

原创 Linux操作系统 作者:yyp2009 时间:2012-04-20 14:50:27 0 删除 编辑

                     熊猫大侠一次性能诊断优化十一问

刚才看到  
ORA-600 & ORA-7445 by Maclean.Liu帖子:
http://www.itpub.net/thread-1558212-1-1.html
大家蜂拥而至呐喊受精!

我学习了一下,的确本身碰到这么多的问题,本身不容易
并且能一一记录在案就更不容易了

但是有些我是这样看的
碰到这么多  
不过看了几篇没什么 特别的
不过是 metlink/sr 和bug 说

不过还是有不少学习的地方

授精个人觉得有待商榷

是不是 bug 原因有可能是更深层次的?
是不是问题“想当然”的就这样?

很多归于bug 有时候是不严谨和科学的
很多想当然的得出结论是轻率的和不科学的

凡事都需要多问个为什么的
由看熊猫大侠想开去:
比如 我昨晚看到的熊军的一文:
修改隐含参数_library_cache_advice解决性能问题一例
http://www.laoxiong.net/resolve- ... meter.html#more-857
要是我们说不好问题就定位为shared pool latch结案,还欣欣然的离开
可人家最终会思考到shared pool simulator latch的竞争

个人表示很敬佩人家的这种精神和境界!!

看看此文中熊军疑惑的“为什么呢?”————————
从Load profile数据对比来看,应用调整后系统负载有一定的提高,同时每事务逻辑读也有一定的增加(不足10%)。这会是个问题吗



最直观的,最容易想到的就是,性能问题的出现是否与应用调整有关,如果是,为什么另一套库没有出现问题

会不会是另一套库的负载在2个节点都有相对均衡的负担,而出问题的库,负载全部集中在1个节点上引起
客户是在应用调整几天后才报告性能问题,这个问题会不会是一个逐渐出现的问题

如果一开始就有严重的性能问题,那么应该会很快报告。不过中间跨了一个周末,所以对于”逐渐出现问题“的判断又加了一些难度。
这么多的性能问题相关的现象中,哪个更贴近问题的原因

实际上在主机的CPU长期保持在100%左右时,会放大平时的一些轻微的问题,或者引起另一些问题。从等待来看,latch: cache buffers chains和cursor: pin S都会引起CPU的急剧增加,而其他的latch竞争同样也会引起CPU的上升,虽然上升没有前者大。到底是SQL执行效率不高引起CPU急剧增加然后引起了shared pool latch等与解析相关的资源争用还是因为解析相关的问题导致CPU急剧增加引起了cache buffers chains等与SQL执行相关的latch争用

或者是2者的共同作用

虽然性能问题已经解决,但是留下来需要更深入的问题还有:
cursor: pin S这个等待,在shared pool simulator latch争用时,是如何产生的

share pool simulator latch的争用是如何产生的,为什么之前没有,是什么引起的

是BUG吗

如果是BUG又是怎么触发的

实际上后面尝试将”_library_cache_advice”参数改回为TRUE,但是该性能问题并没有再次出现。
……

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13750068/viewspace-721805/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 熊猫大侠十一问
请登录后发表评论 登录
全部评论

注册时间:2008-10-17

  • 博文量
    330
  • 访问量
    1017772