美创科技技术社区

注册

 

发新话题 回复该主题

资源供给:CPU [复制链接]

1#

    简单的案例说明:
           某运营商的经营分析系统,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的曲线:是平稳波动的曲线还是锯齿形曲线,锯齿形曲线往往意味着调度不当。

分享 转发
TOP
发新话题 回复该主题