ITPub博客

首页 > Linux操作系统 > Linux操作系统 > cpu time 分析

cpu time 分析

原创 Linux操作系统 作者:zhengbao_jun 时间:2011-04-01 15:37:27 0 删除 编辑

kamus在他的blog10gRAC培训 - 2 and last。说到了这个cpu time,具体可以看正文以及下面我与他的留言,他的意思其实就是:

CPU Time相对于其它等待事件,应当先忽略CPU Time,处理其它等待事件。而且cpu time高一般代表是好事情,因为系统并没有把时间耗费在Wait上。Elapsed Time = CPU Time + Wait Time,所以甚至我们可以说CPU Time越高越好。

不是说他的不对,只是比较觉得这句话太容易误导别人,所以,给一些补充建议,我同意如果有很明显的其它事件,而cpu time不明显的时候,可以优先处理其它事件。但是,还有以下2个地方需要注意:

1、cpu time高一般代表系统的逻辑读大,或者是高计算型的东西,如case函数,decode函数,自定义的计算类型函数等等,把cpu给耗光了,但是这个时候可能根本没有其它等待事件。这样是否证明这个系统很好呢?很可能是,非常不好,因为他很有可能没有必要有这么多的逻辑多,或者是,没有必要有这么多的cpu密集型计算就可以完成的任务,现在消耗这么CPU Time就是不正常的,很容易导致系统负载异常。

2、至于wait time,比如OLTP环境上最典型的db file sequential read引起的等待,是因为发生了物理io而引起的,而很多时候,物理读是随逻辑读增加而增加的,而逻辑读可能会导致cpu time高,也就是说,cpu time与wait time一般是同时增加的。特别是比较高访问量,大数据量,大SGA的系统,逻辑读与物理读都比较高,除了cpu time与db file sequential read,可能不会有很明显的其它等待事件,而优化的结果可能是cpu time与wait time同时减少。

既然说到了db file sequential read,也解释一下这个事件,与cpu time一样,很多时候说明系统是比较正常的,一个优化非常良好的系统,很可能第一个等待事件就是它。因为没有一个系统,不会发生任何物理IO,既然有物理IO,当然db file sequential read就是最好的了,一般表示读数据正常。同样的理由,db file sequential read大了,也可能预兆系统有不该有的物理读发生了。

如一个看起来很正常的sql语句,单个语句效率看起来并不差,执行时间已经小于0.01秒。假定原来逻辑读每个语句平均是100个,物理读平均10个,执行次数每小时50万次,优化完成以后,逻辑读降低为平均50个,物理读平均5个,那么,每小时降低的逻辑读总量就是50*50w=2500w个,降低的物理读为5*50w=250w个。那么再假定每个cpu每秒处理100000个逻辑读就达到了极限,每个物理读需要等待8ms,那么,就可以减少约2500w/100000*3600=7%的CPU使用率(单CPU),可以减少250w*8ms=20000秒的总io wait time。

同理,如果能采用同样的方法,减少执行次数从每小时50w到每小时25w,则收到的效果是一样的。

评价这个cpu time与db file sequential read是否正常,需要很多调优的经验,不过,需要记住的是,任何情况下,不要绝对的说好还是不好。最好的方式就是从statspack或者是awr上看看,排在cpu time,或者是物理读top的语句,他们是否应当有这么大的消耗,他们是否应当执行这么多的次数。

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

请登录后发表评论 登录
全部评论

注册时间:2008-08-08

  • 博文量
    209
  • 访问量
    869782