性能调优中如何定位性能瓶颈

发表于:2011-07-19来源:未知作者:领测软件测试网采编点击数: 标签:性能测试
性能测试的概念是什么,基本目的是什么,我想大家都基本清楚,不作详述,总之,性能测试只是测试过程中的一种方式,帮助我们的功能更好的运行,如果功能测试是可用,易用,满足需求、用户使用为目的,性能测试无非就是让这些目的更流畅。没有什么专业的概念,

  性能测试的概念是什么,基本目的是什么,我想大家都基本清楚,不作详述,总之,性能测试只是测试过程中的一种方式,帮助我们的功能更好的运行,如果功能测试是可用,易用,满足需求、用户使用为目的,性能测试无非就是让这些目的更流畅。没有什么专业的概念,无非实现两个字:好用!

  所以,性能测试这种测试方式在发生过程中,其中一个过渡性的工作,就是对执行过程中的问题,进行定位,对功能的定位,对负载的定位,最重要的,当然就是问题中说的“瓶颈”,接触性能测试不深,更非专家,自己的理解,瓶颈产生在以下几方面:

  1、网络瓶颈,如带宽,流量等形成的网络环境

  2、应用服务瓶颈,如中间件的基本配置,CACHE等

  3、系统瓶颈,这个比较常用:应用服务器数据库服务器以及客户机的CPU,内存,硬盘等配置

  4、数据库瓶颈,以ORACLE为例,SYS中默认的一些参数设置

  5、应用程序本身瓶颈,

  针对网络瓶颈,现在冒似很少,不过也不是没有,首先想一下如果有网络的阻塞,断网,带宽被其他资源占用,限速等情况,应用程序或系统会是什么情况,针对WEB, 无非是超时,HTTP400,500之类的错,针对一些客户端程序,可能也是超时,掉线,服务器下发的,需要服务器返回的信息获取不到还有一种更明显的情 况,应该就是事务提交慢,如果封装事务的代码再不完善,一般造成的错误,无非就是数据提交不完整,或者因为网终原因+代码缺陷造成重复性提交。如此综合下 来,肯定是考虑网络有瓶颈,然后考虑网络有问题时,怎样去优化,是需要优化交互的一些代码,还是接口之类的。

  应用服务的瓶颈的定位,比较复杂,学习中, 不过网上有很多资料可以参考的。一般像tomcatweblogic之类的,有默认的设置,也有经过架构和维护人员进行试验调试的一些值,这些值一般可 以满足程序发布的需要,不必进行太多的设置,可能我们认识的最基本的就是JAVA_OPTS的设置,maxThreads,time_out之类的参数我 们做借助LR,Jemeter或webload之类的工具,执行性能测试,尤其是对应用服务造成了压力,如果应用服务有瓶颈,一般我们设置的 log4j.properties,日志都会记录下来。然后根据日志,去进一步确定应用服务的问题

  系 统瓶颈,这个定位虽说比较复杂,但是有很多前辈的经验值参考,不作说明,相信用LR的同行,也可以从性能记数器中得出一些指标值,加上 nagios,cacti,可以很明显的看出系统哪些资源够用,哪些资源明显不够用。不过,一般系统瓶颈的造成,是因为应用程序本身造成的。关于这点儿的 分析和定位,就需要归入应用程序本身瓶颈分析和定位了。

  现在基本所有的东东,都离不开数据库这个后台,数据库的瓶颈实在是不知道是什么概 念,数据库管理员的工作,数据库管理员日常做的工作,可能就是有瓶颈定位的工作,比如:查询一下 V$sys_event,V$sysstat,v$syssql之类的表,比对一下日常正常情况下的监控数据,看一下有没有异常等。其他方面,我也不是太 了解。

  应用程序瓶颈,这个是测试过程中最需要去关注的,需要测试人员开发人员配合执行,然后定位,我这儿做的大都是执行性的,比如会有脚本去运行,开发人员会结合jprofiler之类的工具,去看一下堆遍历,线程剖析的情况确定哪儿有问题。大致是这样,没有实际操作过

  逐步细化分析,先可以监控一些常见衡量CPU,内存,磁盘的性能指标,进行综合分析,然后根据所测系统具体情况,进行初步问题定位,然后确定更详细的监控指标来分析。

  怀疑内存不足时:

  方法1:

  【监控指标】:Memory Available MBytes ,Memory的Pages/sec, page read/sec, Page Faults/sec

  【参考值】:

  如果 Page Reads/Sec 比率持续保持为 5,表示可能内存不足。

  Page/sec 推荐00-20(如果服务器没有足够的内存处理其工作负荷,此数值将一直很高。如果大于80,表示有问题)。

  方法2:根据Physical Disk 值分析性能瓶颈

  【监控指标】:Memory Available MBytes ,Pages read/sec,%Disk Time 和 Avg.Disk Queue Length

  【参考值】:%Disk Time建议阈值90%

  当内存不足时,有点进程会转移到硬盘上去运行,造成性能急剧下降,而且一个缺少内存的系统常常表现出很高的CPU利用率,因为它需要不断的扫描内存,将内存中的页面移到硬盘上。

  怀疑内存泄漏时

  【监控指标】:Memory Available MBytes ,Process\Private Bytes和Process\Working Set,PhysicalDisk/%Disk Time

  【说明】:

  Windows资 源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,则很可能存在内存泄漏。内存泄漏应该通过一个长时间的,用来研究分析当所有内存都耗尽时,应用程序反应情况的测试来检验。

  CPU分析

  【监控指标】:

  System %Processor Time CPU,Processor %Processor Time CPU

  Processor%user time 和Processor%Privileged Time

  system\Processor Queue Length

  Context Switches/sec 和%Privileged Time

  【参考值】:

  System\%Total processor time不持续超过90%,如果服务器专用于SQLServer,可接受的最大上限是80-85% ,合理使用的范围在60%至70%。

  Processor %Processor Time小于75%

  system\Processor Queue Length值,小于CPU数量的总数+1

  CPU瓶颈问题

  1、System\%Total processor time如果该值持续超过90%,且伴随处理器阻塞,则说明整个系统面临着处理器方面的瓶颈.

  注:在某些多CPU系统中,该数据虽然本身并不大,但CPU之间的负载状况极不均衡,此时也应该视作系统产生了处理器方面的瓶颈.

  2、 排除内存因素,如果Processor %Processor Time计数器的值比较大,而同时网卡和硬盘的值比较低,那么可以确定CPU 瓶颈。(内存不足时,有点进程会转移到硬盘上去运行,造成性能急剧下降,而且一个缺少内存的系统常常表现出很高的CPU利用率,因为它需要不断的扫描内 存,将内存中的页面移到硬盘上。)

原文转自:http://www.ltesting.net