ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 测量、基线和性能优化之三:基于测量、基线和变化的性能优化

测量、基线和性能优化之三:基于测量、基线和变化的性能优化

原创 Linux操作系统 作者:sunsapollos 时间:2013-10-22 21:36:56 0 删除 编辑
        我们建立了可测量的指标,为可测量的指标建立了基线,确立了基于变化的性能优化诊断理论,性能优化诊断就成为水到渠成的事情了,而通过可测量指标的相关性分析就可以轻松的对于性能进行改善,从而完成性能优化工作。
         回到我们的吞吐量曲线基本图:
        
        我们采用最简单的模型来进行基于变化的性能优化实践

         吞吐量:= ( 60/响应时间 ) * 并发Session数量
         响应时间:= 服务处理时间 + 服务排队(等待)时间
         服务处理时间:= 单元服务次数 * 单元服务时间  
         服务等待时间:= 单元服务次数 * 单元服务等待时间
                                 := IO等待次数*IO等待时间 + 并发性等待次数*并发性等待时间 + 其他等待次数 * 其他等待时间

         可测量的基线指标(峰值):
         响应时间:=1560ms
         并发数:    =100
         吞吐量:    = 3846
         服务处理时间:=  3894秒
         单元服务次数:=  9500
         单元服务时间:=  410ms
         服务等待时间:=  2096秒
         单元服务等待时间:= 220ms
         IO等待次数:=100
         IO等待时间:=2ms
         并发性等待次数:=2000
         并发性等待时间:=0.01ms
         其他等待次数:= 0
        
         发生性能问题之后以上可测量的指标观察到:
         响应时间:=5000ms
         并发数:    =250
         吞吐量:    = 3000
         服务处理时间:=  3750秒
         单元服务次数:=  7421
         单元服务时间:=  505ms
         服务等待时间:=  11250秒
         单元服务等待时间:= 1516ms
         IO等待次数:=78
         IO等待时间:=20ms
         并发性等待次数:=1560
         并发性等待时间:=0.01ms
         其他等待次数:= 0
       
         通过以上可测量指标的简单比较可以发现:响应时间增加,并发数增加,吞吐量下跌。进一步比较可以发现响应时间增加主要原因为单元服务等待时间从220ms增加到了1516ms,单元服务时间略有增加。而单元服务等待时间的增加主要是由于单元IO等待时间的变化引起,从2ms增加到了20ms。通过和基线指标数据的变化比较可以很简单作出诊断:IO子系统出现问题导致响应时间增加,而通过我们对于IO子系统的知识储备可以知道20ms的响应只有两种可能性:(1)、IO严重堵塞  (2)、IO子系统出现故障类事件(配置或者其他)。从IO发生次数可以知道,严重堵塞的可能性不大(并非绝对没有,比如很多数据库外的负载),我们的调整方向就走向IO子系统故障,检查其配置和状态,检查其IO子系统组成链路。
        这个时候我们可以进一步检测磁盘系统的基线:
        磁盘利用率:=98%
        iops:= 3600
        服务响应时间:= 2ms

        各位读者可以想象一下,如果缺乏基线数据,相当多的优化工作者可能会通过调整SQL语句降低IO数量来完成本次优化。

        
            

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

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

注册时间:2013-10-15

  • 博文量
    68
  • 访问量
    725131