ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Oracle QQ群讨论系统性能Tuning话题总结(1)

Oracle QQ群讨论系统性能Tuning话题总结(1)

原创 Linux操作系统 作者:tolywang 时间:2007-09-28 00:00:00 0 删除 编辑

以下是群中牛牛 爱你如初 老大的一些谈话总结。 有一些概念性的东西我会在回复中写出来。供大家参考。

应用跟我的反映98%就是慢 , 一般会按照下面步骤进行

1、打开TOPAS (AIX),查询IO CPU情况

2、检查应用服务器的情况

一般时候到这里就会出现2中情况 , 数据库服务器CPU很高 或者IO很高


3、查询RAC节点的日志和OS的日志确认不存在OS或者数据库本身出现了问题 , 比如FSP卡出现问题或者内存模块出现问题等等都要先排除

4、检查存储日志

如果检查OS以后发现CPUIO都不高,前台还反映慢,那就开始考虑网络了

5、然后开始着手查数据库本身与应用的问题了,一般我都会通过排名前几的进程去查在后台执行什么动作由于像我们这些系统执行频度很高,所以语句的切换是非常快的大部分时间都是花在这里

记得有回,我们的一个节点CPU利用率很高,但是经过对大量语句的分析,每条语句的执行都不会超过0.1S , 而且这些语句都是一闪而过, 这个时候我会特别注意这些语句执行的频度, 最后发现有个语句每秒执行接近100 , 你想想即使这个语句每次执行001S,那么一秒种也需要用掉你大量的CPU .

如何查询每秒执行接近100, v$sqlarea里去查, 如果绑定过的 , 里面会记录一个执行次数 , 你可在2个时间点执行相减下就可以算出来了, 对绑定不好的情况,情况就更复杂了 .

比如前天我们这里出现的问题, DBA跟我反映说从上午940开始,主服务器的CPU一直攀身从20%一直差不多到80% , 这种情况是属于比较紧急时刻了, 但是经过对大量语句排查后没有发现任何异常 , 然后我检查了下v$session_wait , 发现里面有少量的LATCH FREE等等 , 我再看看v$sqlarea,发现前天晚上执行的一些大量的非绑定语句存在 , 这个问题就跟10G的内存自动管理就有点关系了 , 我一直不很推崇10G的对于SHARED POOL自动管理的能力 , 我曾经做过测试,在10G下和9I下做压力测试,在相同情形下,都不进行变量的绑定, 9I的效率到后期差不多是10G30 , 10G对于SHARED POOL自动管理是存在缺陷的, 比如他在什么时候停止申请新内存等等应该是没控制好的 , 没控制好直接导致SHARED POOL的进出队列管理也存在了缺陷 ,也就是当SHARED POOL内存用了到达一定程度的时候,那么ORACLE本身对这片内存区的管理尤其是在变量绑定不好的时候 , 那代价是极其高的 . 不过这个问题我从没看到过有人在论坛上提过 , 这个时候有个小巧的解决办法, 我一般都那么处理, 果也是相当不错的 , 一般这个时候我会把SHARED POOL给清空(alter system flush shared pool ) , 我们前2天的问题我把内存清掉以后 , CPU马上下到20% . flush之后,应用语句绑定好 ,虽然所有请求都需要hard phase一次,但是基本没有大的影响。

接着谈谈FLUSH的作用? 举个例子吧, 例子好理解些 ,举个排队的例子,如果一个队伍里总共就2个人,只要一个管理员就可以管得好好的 , 但是如果一个队伍有2万个人 ,那需要多少管理员去管理才能管理好这个队伍呢?实际上就是一个PIN的动作, 因为变量没绑好, 很多PARSE的时候都要去PIN这个OBJECT, 所以会出现LATCH FREE等带 , LATCH可以理解为是一个内存保护锁 , 一块内存区的数据一个时刻只能被某一个进程读取占用 , 实际上在内存区不够的时候也会出现这种等待时间了

我当时为什么说怀疑ORACLESHARED POOL的管理上是否有问题呢 ,按照一般情况就好比9I的处理方式, 一般时候他的LRU队列管理是很正常的怎么进队列出队列都有严格的规则 .

待续...........

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

请登录后发表评论 登录
全部评论
Oracle , MySQL, SAP IQ, SAP HANA, PostgreSQL, Tableau 技术讨论,希望在这里一起分享知识,讨论技术,畅谈人生 。

注册时间:2007-12-10

  • 博文量
    5595
  • 访问量
    13200956