资源供给：再谈CPU

       虽然CPU利用率达到100%并不是判断CPU是否有效的足够依据，但100%的CPU会带来一定问题，就是我们无法判断CPU究竟是足够有效还是完全跟不上。对于OLTP并发还可以通过CPU Queue来完成观察，对于批处理应用我们几乎无法来判断是否有问题，只能依据业务层面的数据来判断CPU是否给足够有利。
      对于数据库类应用，我们可以简单的采用CPU Time Per IO来进行有效性判断，也就是每个IO需要消耗多少CPU Time，每秒吞吐量的LIO需要消耗多少CPU Time来确定。

      如何让CPU更加有效的处理，自然最主要是降低各种上下文的切换，使CPU专心处理事情，并且不要使其无事可做。这个观点，目前我并没有做过测试案例的验证，只是一个假设，从直观上来说结论应该成立。我们以两个例子来说明情况：
     （1）、Bind in 和 BInd out
     Bind out:
          declare
              l_name varchar2(100);
              l_stat   varchar2(10);
              cursor tcur is select name,status from customer where rownum<100;
          begin
              for i in tcur loop
                 l_name:=i.name;
                l_stat:=i.l_stat;
              end loop;
         end;
        在这个过程中Oracle CPU的消耗是很高的，但是效率并不会很高，尤其这个cursor如果不是PLSQL Cursor，而是一个CLient Cursor的时候。CPU需要不断在不同的状态之间进行转换。
      
        declare
          type l_namet is table of varchar2(100);
          type l_statt is table of varchar2(10);
          l_name l_namet;
          l_stat   l_statt;
       begin
       select name,status collection into l_namt,l_stat from customer where rownum<100;        
      end;       

         比较上面的逐行cursor处理，这个处理实现了集中获取集中输出结果，使CPU处于简单工作，其利用效率会很高。

     （2）、Fetch Rows
       同样，我们fetch处理的时候，每次fetch 1行和每次fetch 100行，其CPU处理效率会发生很大不同。fetch 1行很有可能会导致CPU会无法被充分利用。

      当我们遇到CPU Queue很大，但CPU利用率不高的时候怎么办？
      这种情况只会是四个问题：第一，CPU调度能力不够，这个可能不是我们所考虑的，相信应该也会比较少遇到。
                                                  第二，CPU总是被各种事件所打扰，特别是软终端。
                                                  第三，CPU处理效率不高，内存匹配度不够，比如大量页面读
                                                  第四，CPU没有太多的东西处理，使其处于空闲状态
     
       以上也是仅仅处于推理状态，必要的时候需要通过测试案例去验证，如果已经有人验证了上述观点正确或者错误，我就不用费时费力去验证了，时间很宝贵。我写这些东西，最大的问题在于平时习惯不好积累不够，需要通过测试案例重构去展现问题。不过各位也知道，可以重构的案例处理，往往意味着其理论是正常。

       对于数据库应用来说，有一类应用的CPU消耗过高，不要说100%，即使30%等都会出现问题，那就是Orace后台进程。

       和普通用户进程不同，Oracle后台进程为所有的用户进程提供服务，其过高的CPU意味着这些进程由太多的任务要处理，太多的任务要处理往往就意味着有太多的任务等待着他去处理，用户进程九需要等待他去完成，从而影响用户进程的效率。
       常见的CPU会出现大问题有如下进程：
       Listener进程
      Smon进程
      dbwr进程
       lgwr进程
      lms进程
       lck进程
      lmd进程

      特别是lms进程，在设计不良的RAC系统，经常会看到100%的CPU利用率。遗憾的是，在绝大部分情况下，这些进程的CPU利用率你很难有所作为，负载分担是一个通常的方法。

      比如：Listener进程一般意味着过大的Session压力，简单性的调整往往效果有限，这个时候你只能增加Listener进程数量以求分担负载。
      SMon进程往往意味着大型的事务回滚，你也只能等待他完成
      lgwr进程往往意味着过多的事务要处理，你只能期待开发商调整commit的频率。
      。。。。。


      最后一句话，CPU利用率的高的系统往往是优良的系统。有一句行话：未经过优化的系统往往是IO瓶颈，而经过优化的系统应该是CPU瓶颈。
      为什么要如此说？
      CPU是计算机系统中最昂贵的部件，也是处理速度最快的部件，当然要把他的能力都发挥出来，这个时候投资回报率是最高的。

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

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