LoadRunner性能测试指标分析
Memory:
·Available Mbytes
简述:可用物理内存数.如果Available Mbytes的值很小(4 MB或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
参考值:4 MB或更小,至少要有10%的物理内存值
·Page/sec (Input/Out)
简述:为了解析硬页错误,从磁盘取出或写入的页数。
一般如果Page/sec持续高于几百,那么您应该进一步研究页交换活动。有可能需要增加内存,以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。Pages/sec的值很大不一定表明内存有问题,而可能是运行使用内存映射文件的程序所致。
参考值:
·Page Fault
简述:处理器每秒处理的错误页(包括软/硬错误)。当处理器向内存指定的位置请求一页(可能是数据或代码)出现错误时,这就构成一个Page Fault。如果该页在内存的其他位置,该错误被称为软错误(用Transition Fault/sec记数器衡量);如果该页必须从硬盘上重新读取时,被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是,硬错误可以导致明显的拖延。
参考值:
·Page Input/sec
简述:为了解决硬错误页,从磁盘上读取的页数。
参考值:
·Page reads/sec
简述:为了解决硬错误页,从磁盘上读取的次数。解析对内存的引用,必须读取页文件的次数。阈值为>5.越低越好。大数值表示磁盘读而不是缓存读。
参考值:
·Cache Bytes
简述:文件系统缓存,默认情况下为50%的可用物理内存。如IIS5.0运行内存不够时,它会自动整理缓存。需要关注该计数器的趋势变化。该指标只显示最后一次观察的值,它不是一个平均值。
参考值:
·pool paged bytes
简述: 指在分页池中的字节数,分页池是系统内存中可供对象使用的一个区域。
·pool nonpaged bytes
简述:指非分页池中的字节数,非分页池中的字节数如果持续增加表示可能存在内存泄漏问题,需要进一步结合其他指标,来判断是否存在严重的内存泄漏还是其他原因引起的非分页池增加。
·内存泄露
简述:
如果您怀疑有内存泄露,请监视Memory\\ Available Bytes和Memory\\ Committed Bytes,以观察内存行为,并监视您认为可能在泄露内存的进程的Process\\Private Bytes、Process\\Working Set和Process\\Handle Count。如果您怀疑是内核模式进程导致了泄露,则还应该监视Memory\\Pool Nonpaged Bytes、Memory\\ Pool Nonpaged Allocs和Process(process_name)\\ Pool Nonpaged Bytes。
参考值:
Process
·Page Faults/sec
简述:将进程产生的页故障与系统产生的相比较,以判断这个进程对系统页故障产生的影响。指每秒钟出错页面的平均数量。
参考值:
·Private Bytes
简述:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低,则此计数器可以是内存泄漏的最佳指示器。
参考值:
·Work set
简述:处理线程最近使用的内存页,反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存,页就会被留在工作集中,当自由内存少于一个特定的阈值时,页就会被清除出工作集。
参考值:
Processor
·% Processor Time
简述:CPU利用率,可以查看处理器是否处于饱和状态,此值的最佳范围为75%-95%,如果在性能监控过程中此值过低,表示CPU尚未充分利用,还 需要更大的负载压力,如果该值持续超过95%,就表示当前系统的瓶颈为CPU,此时可以考虑增加一个处理器或换一个性能更好的处理器。
参考值:
·ProcessorQueue Length
简述:判断CPU瓶颈,如果processor queue length显示的队列长度保持不变(>=2)并且处理器的利用率%Processor time超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.
参考值:
·interrupt/sec
简述:指处理器接收并维护硬件中断的平均值,单位是事件数/秒,这 个值说明了能够产生中断的设备(如系统时钟、鼠标、磁盘驱动器、网卡和其他外部设备)的活动情况,这些可以产生中断的设备通常在完成了一项任务时中断处理器。
·%user
time
简述:指处理器处于用户模式的时间百分比,也就是非内核操作用户进程所耗费的CPU时间。其值可以表示为CPU的数据库操作(如查找、排序等活动)耗费的时间,如果该值很高,可以考虑增加索引、使用简单的表连接、水平分割大表格等方法来降低该值。
计算机处理器有用户模式和特权模式两种工作方式,用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式;特权模式是为操作系统组件设计的,允许其直接访问硬件和所有内存。操作系统将应用程序线程转换成特权模式以访问操作系统服务器。
·%privileged Time
简述:指处理线程执行代码所花时间的百分比。如果该参数值和“physical disk”值一直很高,表明I/O有问题,可考虑采用更快的硬盘系统。
·%interrupte time
简述:处理器在实例间隔期间接受和服务硬件中断的时间。此值间接表示了产生中断的设备的活动,如系统时钟、鼠标、磁盘驱动器、网卡和其他外部设备,这些设备通常会中断处理器。
·%DPC time
简述:指在实例间隔期间,处理器用在延缓程序调用(DPC)接收和提供服务的时间百分比,就是消耗在网络处理上的时间,该值越低越好。由于DPC是以特权模式执行的,DPC时间的百分比为特权时间百分比的一部分。
·Queue Length
简述:指跟踪服务器工作队列当前长度的计数器,该数值会显示出处理器瓶颈。队列长度持续大于2则表示可能出现处 理器拥塞。
·
Physical Disk
·%DiskTime
简述:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
正常值<10,此值过大表示耗费太多时间来访问磁盘,可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和),则可能是内存泄漏。
参考值:
·CurrentDiskQueueLength
简述:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。(磁盘数1.5-2倍)
参考值:
·Avg.Disk Queue
Length
Avg.Disk Read
QueueLength
Avg.Disk Write
QueueLength
Disk Read/sec
Disk Write/sec
简述:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。
磁盘瓶颈判断公式:
每磁盘的I/O数=(读次数+(4*写次数))/磁盘个数。
如果计算出来的每磁盘的I/O数大于磁盘的处理能力,那么磁盘存在瓶颈。
参考值:
Avg.DiskQueue Length正常值<0.5,此值过大表示磁盘IO太慢,要更换更快的硬盘。
综合判断:
1、处理器队列堵塞判断方法:如果Processor queue length大于2,而处理器利用率一直很低,则存在处理器堵塞。
2、处理器瓶颈判断方法:排除内存因素后,如果%processor time持续大于90%,并且%interrupt time的值持续大于15%,同时网卡和硬盘的值比较低,可以断定处理器负荷过重,无法满足业务增长需要,处理器是系统瓶颈点。
3. 监视内存不足的状况,可以通过 page/sec,Available Mbytes、page read/sec、page faults/sec等计数器的指标进行监控,还可以通过使用“页面交换”的频率来衡量。
“页面交换”是使用称为“页面”的单位,将固定大小的代码和数据块从RAM移动到磁盘的过程,从而释放暂时不使用的空间,这些页面文件就是操作系统用来虚拟内存的硬盘空面。操作系统对于虚拟内存主要设置两点,即内存页面文件的大小和页面文件存放的位置,内存页面文件的大小就是设置虚拟内存最小和最大空间量,而页面位置则是设置虚拟内存使用哪个分区中的硬盘空间。
频繁的页面交换将降低系统性能,如果系统“页交换”频繁,说明内存不足。通过调优配置减少页交换,将显著提高系统响应速度。
4. 通过pages/sec指标判断是否存在内存问题,如果pages/sec持续高于几百,则有可能需要增加内存,以减少换页的需求,此时还应该进一步研究页交换活动。如果pages/sec指标过高(几百),而硬盘数据流量不高(几百kb/s)则可确定是内存不足问题,如果pages/sec指标较高(几百),而此时硬盘数据流量也很高(几千KB /S),则可以判定是磁盘问题。
5.通过 available mbytes来判断是否存在严重内存泄漏问题,如果该值很小(<4M),则说明计算机上总的内存可能不足,或者某个程序始终占用而没有释放内存,系统存在严重的内存泄漏问题。
6.如果页面读取操作速率page reads/sec指标的值很低,同时%disk time和avg.disk queue length的值却很高,则确定为磁盘瓶颈,但如果Avg.sidk queue length增加的同时page reads/sec页面读取速率指标并未降低,则确定为内存不足。
注:在run里面输入perfmon即可打 开本机监视器
LoadRunner性能测试指标分析的更多相关文章
- LoadRunner性能测试结果分析(转载)
性能测试的需求指标:本次测试的要求是验证在30分钟内完成2000次用户登录系统,然后进行考勤业务,最后退出,在业务操作过程中页面的响应时间不超过3秒,并且服务器的CPU使用率.内存使用率分别不超过75 ...
- LoadRunner性能测试结果分析
LoadRunner性能测试结果分析http://www.docin.com/p-793607435.html
- Jmeter性能测试指标分析
一.Aggregate Report 是 JMeter 常用的一个 Listener,中文被翻译为"聚合报告 如果大家都是做Web应用的性能测试,例如访问百度请求为例,线程10,循环10次, ...
- LoadRunner 各个指标分析
我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.%processor time(processor_total):器消耗的处理器时间数量.如果服务器专用于sql server 可 ...
- [转]LoadRunner 各个指标分析
转载:https://www.cnblogs.com/dvbbs2012/p/4073635.html 我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.%processor ti ...
- LoadRunner性能测试样例分析
LR性能测试结果样例分析 测试结果分析 LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源 ...
- loadrunner测试结果分析
LR性能测试结果样例分析 测试结果分析 LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源 ...
- Loadrunner测试实例分析
LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源.数据库服务器资源等几个方面分析,如图1 ...
- Web项目性能测试结果分析
1.测试结果分析 LoadRunner性能测试结果分析是个复杂的过程,通常可以从结果摘要.并发数.平均事务响应时间.每秒点击数.业务成功率.系统资源.网页细分图.Web服务器资源.数据库服务器资源等几 ...
随机推荐
- Maven pom项目部署
maven控制台运行程序 <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec- ...
- tfs 清除缓存,在需要时
C:\Users\xxx\AppData\Local\Microsoft\Team Foundation\5.0
- viusal studio 调试错误及解决方法(长期更新记录)
1.为了看运行结果加了 system("pause"):结果导致图像显示不出来,数据为空.主要是因为system pause后停止计算.图像显示不出来.应该改成:waitKey(0 ...
- haoce修改mysql
修改时长余额 select * from sys_user_product up where up.user_id in(select u.id from sys_user u where login ...
- selenium自动化遇见Cannot find class in classpath问题
今天遇见了Cannot find class in classpath的问题, org.testng.TestNGException: Cannot find class in classpath: ...
- jQuery EasyUI的使用入门
jQuery EasyUI不是什么太高级的东西,就是用jQuery写了很多方法.定义了很多属性,通过调用这些方法.属性,可以达到一些特定的效果,然后我们再根据具体需求微调就好了.至少需要导入两个样式表 ...
- Spring-MVC填坑之旅-返回json数据
本文是自己开发中所遇到的问题,对一些及百度到的解决方案做一个记录. DispatcherServlet配置文件 <!-- 定义跳转的文件的前后缀 ,视图模式配置--> <bean i ...
- Webpack学习笔记(一)
转载http://zhaoda.net/webpack-handbook/module-system.html 转载http://www.cnblogs.com/vajoy/p/4650467.htm ...
- uva 12356 Army Buddies
简单的并查集应用. #include<stdio.h> #include<string.h> #include<math.h> #include<algori ...
- RabbitMQ高可用配置(Haproxy + Keepalived)
网络结构如下图: 共有104.105.106三台RabbitMQ Server,互为集群 其中104和105安装了Haproxy,每个Haproxy承担三台RabbitMQ server的负载均衡 两 ...