资源供给：CPU

       简单的案例说明：
       某运营商的经营分析系统，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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/92650/viewspace-776149/