ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 资源供给:CPU

资源供给:CPU

原创 Linux操作系统 作者:sunsapollos 时间:2013-11-08 22:50:27 0 删除 编辑
       简单的案例说明:
       某运营商的经营分析系统,ETL完成时间不能让人满意,期望在6:30,最晚7:00完成的ETL作业总是在9:00多才完成,老板意见很大,信息化部门压力很大。注意这是一个DB2数据库,我不懂DB2,这个案例很清晰的说明了优化方法的通用性。DB2的服务供应商给出了优化SQL的解决方案,我简单看了优化的SQL方案,直接就认为优化方案是无效的,不会产生效果。确实,服务商在辛苦了半个月之后毫无收获,我看了他们的系统,非常简单的调整,明确认为应该可以完成2小时的时间节约。措施非常简单,只是把ETL作业进行了均匀调度,使其平稳的分布在从10:00开始的时间范围内,而不是像原来一样空闲几个小时,运行几个小时,然后又空闲一段时间。由于同时派生的进程运行太多,导致CPU和IO都100%忙碌,达到硬件限制。只要我们适当的把资源分布就可以降低在CPU和IO资源的冲突,最大程度的利用资源,从而提高程序响应速度。
       最后开发商没有做任何调整,只是简单的调整了运行时间和并发控制,有意识的安排程序错开运行,ETL速度平稳的加快了2个多小时,达成了优化目标。
          
    
      业务系统的运行依赖于资源供给,Oracle数据库所有的资源来源于OS,OS所有的资源来源于依赖的硬件。CPU,Memory,Network,IO SubSystem。CPU可以说是其中最重要的资源,CPU,中央处理器,在所有部件中唯一一个主动性部件,其他任何部件都依赖于CPU的调度,属于被动响应。可以看到Oracle把CPU运行部分表示为服务时间,其他部分表示为等待时间。
       很遗憾,CPU是所有硬件资源中最不具有柔韧性的部件,你几乎无法通过扩容去完成他,你很难因为资源不足去增加CPU数量,或者CPU主频不够去增加主频。作为一个性能优化者,几乎不需要去关注CPU的运行细节,特别在数据库应用中,CPU的能力事实上取决于内存系统,因为绝大部分操作是内存操作而非是运算操作。
      CPU做什么事情:
      运算
      内存操作
      页面交换
      进程上下文切换
      响应中断
      网络内存处理

      如何衡量一个CPU的性能?
      CPU利用率和CPU Queue
   
     CPU利用率100%是否意味着性能不好?
    我们很难说CPU 100%是否意味着性能不好,如果这个100%的CPU都花在运算和内存操作上,大多数情况下我们认为这笔投资是最划算的,只是系统不具有扩展性而已。尤其对于批处理而言,我们总是希望100%的利用CPU,任何CPU资源的浪费就是意味着我们的代码写的不够好。

    CPU利用率 100%,没有告诉他确实100%的全力运行,还是他已经在过载运行事实上CPU性能已经在下跌。不过个人感觉,CPU作为电子设备,过载运行的可能性不会很高,100%基本表示为其全速运行,如果这个100%的CPU都作用在用户进程上面。

   当在一个OLTP系统CPU利用率100%,在绝大部分情况下都意味着问题,除非其已经处于负载最高峰。
   在OLTP系统中,比较利用率更加重要的指标:CPU Queue,等待CPU资源的运行队列长度。 

    回到我们的RT,RT:= DB time:=CPU Time + Wait TIme
                                                   :=CPU Time + CPU QUeue TIme + Wait time

     Oracle对于CPU Queue TIme并没有明确的记载,我们通过以下方法来计算:CPU Queue Time:=DB TIme - CPU time - Wait time

     CPU从本质上是一个串行设备,在某一时刻只能为某个进程服务,其他进程只能等待。这里事实上可以看出,主频越高,等待的时间将会越短。所有等待的运行进程都会处于CPU Running Queue中,等待获得CPU资源。可以看到CPU资源的切换是一个无效率的操作,可能需要把CPU cache中进程数据被交换出去,从而大幅度影响性能。

     多少的CPU Queue是合适的?
    没有一个绝对的数字,只能说CPu的主频越高,可以接收的数字就越高。在很久以前,10年前吧,那个时候我把1作为运行良好,2就作为运行不好的说法,那时候主频才1G,现在已经4G的主频了,估计可以到4才表示问题了。
    事实上,这个数字多少是依赖于业务系统。如果你的数据库应用严重的依赖于磁盘系统,大量的磁盘IO存在,你在CPU Queue中多等几次也没什么大不了,不会在总时间占用多大的空间。但是如果你是全内存操作,甚至是大部分运算操作,这个队列的大小就成为致命因素,因为业务的CPU渴望很高。
  
    再次回到多少个Queue才合适的?
   我们的说法,(1)、实际运行中的基线数字,如果你实际运行队列是8,依然运行良好,硬要说4就没有意思了。
                         (2)、目前我依据CPU能力取2.5~4的范畴。
   
    事实上CPU Queue的大小可以通过CPU Queue Time的计算来完成。
   上面的公式:CPU Queue Time:=DB TIme - CPU time - Wait time,计算出来的值再合CPU Time比较。当本身在DB Time之中,Wait Time较小的时候,CPU QUeue TIme就会成为一个影响因素。多少合适,10%或者20%,随意而定了,一般感觉还是5~10%是一个可以接收的范畴。

   CPU Queue的根源是从两个方面引起的,(1)、CPU运行不够快  (2)、在某一时刻调度太多的程序
   如何降低CPU消耗?
  对于数据库应用来说,降低CPU消耗主要从以下几个方面来进行:
  (1)、简化业务逻辑
  (2)、降低LIO
  (3)、降低latch冲突
  (4)、减少引擎转换
  (5)、进行合理调度
   
   简化业务逻辑: 这个不说了,谁都知道,大量的业务系统中存在很多的无效操作,优化要阅读代码,对于很多优化工作者是个负担。
   降低LIO: 更加有效的索引,更加有效的parse,更少的fetch
   降低latch冲突:更加有效的parse,更加快的处理速度,更少的冲突
   减少引擎转换:任意的引擎转换都消耗大量的CPU,并且效率低下。
                            降低Bind in and Bind out
                            避免在SQL语句中使用PLSQL函数
                            减少PLSQL和SQL的交互
                            减少SQL和Java等接口语言的交互
                            减少网络交互
   进行合理调度:不要在某一时刻调度大量程序,而是顺序启动或者进行小批量分布。比如要启动10个进程处理,不要在某一时刻同时启动,可以每秒钟启动一个,在10秒之内启动10个程序。

   对于操作系统而言:
   (1)、减少不必要的页面交换
    页面交换大幅度降低CPU的处理能力,数据库类应用的最终能力依赖于内存,当内存缺少的时候,CPU处理能力自然就大幅度下跌。
   (2)、减少进程上下文切换
    过多的进程将很大程度上降低CPU效率,CPU从本质上某一时刻只能为一个进程服务。任何进程的上下文切换都是无效工作。
   (3)、减少网络处理和中断
    网络处理消耗CPU资源,要尽可能的使CPU在一个时钟周期内充分工作,而不是无所事事,也就是说需要让他处理更多的工作。

    CPU资源的监控:
  
    Oracle:  DB CPU Time
                 DB CPU Queue Time
                 OS CPU ratio
                CPU Queue:= Active Session for ON CPU
    OS:
                sar -u
                sar -q
                vmstat
               mpstat
               uptime

    主要指标为:
    CPU Usage ratio:= User CPU+ SYS CPU
  CPU Queue 
  
   辅助指标:
  context swicth
  page swap
  intr number

   CPU Usage的曲线:是平稳波动的曲线还是锯齿形曲线,锯齿形曲线往往意味着调度不当。

     
   
 
   
   
 
  
  


   

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

请登录后发表评论 登录
全部评论
专注于Oracle,BI,Security,DR &^BCP,Performance tuning

注册时间:2013-10-15

  • 博文量
    68
  • 访问量
    726245