【转】如何使用Loadrunner进行资源占用率的分析?(08-12-29)(获奖名单已公布)

上一篇 / 下一篇  2012-03-06 10:58:21 / 个人分类:性能测试

情况比较复杂,有兴趣的话可以就这个问题写本很厚的书。

1. 系统分类
1.1. windows
1.2. unix/linux
2. 核心分类
1.1. 单核CPU
1.2. 多核CPU
3. 应用分类
3.1. JAVA应用
3.2. DotNet应用
3.3. 其他应用
4. 磁盘分类
5. 平台分类
5.1. 中间件平台
5.2. 数据库平台
5.3. 其他中间件平台
6. 综合以上这些内容分析,相信会有很多排列组合。由于参数组合及应用的复杂性,说性能的高低标准实在很难一概而论。只能就事论事,依照情况分析。

之前有过一些分析的帖子和博文,一概拿来主义,分享下(感谢那些曾经整理过并拿来分享的兄弟姐妹)。

原帖请看:《LoadRunner监视的性能计数器》51testing上有。

    Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁,说明内存不足。“页交换”是使用称为“页面”的单位,将固定大小的代码和数据块从RAM 移动到磁盘的过程,其目的是为了释放内存空间。尽管某些页交换使Windows 2000 能够使用比实际更多的内存,也是可以接受的,但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况,请从以下的对象计数器开始:


    Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。


    page/sec: 表明由于硬件页面错误而从磁盘取出的页面数,或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百,那么您应该进一步研究页交换活动。有可能需要增加内存,以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。Pages/sec 的值很大不一定表明内存有问题,而可能是运行使用内存映射文件的程序所致。


    page read/sec:页的硬故障,page/sec的子集,为了解析对内存的引用,必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。

    由于过多的页交换要使用大量的硬盘空间,因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此,在研究内存不足不太明显的页交换的原因时,您必须跟踪如下的磁盘使用情况计数器和内存计数器:


    Physical Disk\ % Disk Time

    Physical Disk\ Avg.Disk Queue Length

    例如,包括Page Reads/sec 和% Disk Time 及Avg.Disk Queue Length。如果页面读取操作速率很低,同时% Disk Time 和Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。

    要确定过多的页交换对磁盘活动的影响,请将Physical Disk\ Avg.Disk sec/Transfer 和Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了0.1,那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况,那么您可能需要更多的内存。


    Page Faults/sec:每秒软性页面失效的数目(包括有些可以直接在内存中满足而有些需要从硬盘读取)较page/sec只表明数据不能在内存的指定工作集中立即使用。


    Cache Bytes:文件系统缓存(File System Cache),默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时,它会自动整理缓存。需要关注该计数器的趋势变化

    如果您怀疑有内存泄露,请监视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。


    Pages per second :每秒钟检索的页数。该数字应少于每秒一页。



Process:


    %Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%


    Page Faults/sec:将进程产生的页故障与系统产生的相比较,以判断这个进程对系统页故障产生的影响。


    Work set: 处理线程最近使用的内存页,反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存,页就会被留在工作集中,当自由内存少于一个特定的阈值时,页就会被清除出工作集。


    Inetinforivate Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低,则此计数器可以是内存泄漏的最佳指示器。


    Processor:监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息,帮助您决定是否存在瓶颈。


    %Processor Time:如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。


    %User Time:表示耗费CPU的数据库操作,如排序,执行aggregate functions等。如果该值很高,可考虑增加索引,尽量使用简单的表联接,水平分割大表格等方法来降低该值。


    %Privileged Time:(CPU内核时间)是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"hysical Disk"参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM,减低"max async IO","max lazy writer IO"等措施都会降低该值。

    此外,跟踪计算机的服务器工作队列当前长度的Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于4 则表示可能出现处理器拥塞。此计数器是特定时间的值,而不是一段时间的平均值。


     % DPC Time:越低越好。在多处理器系统中,如果这个值大于50%并且Processor:% Processor Time非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。


Thread


    ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小,你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数,这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高,就应该减小线程字节池的大小。


Physical Disk:

     %Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大,那么硬盘不是瓶颈。如果只有%Disk Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器之前,请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%,则可能是内存泄漏。


     Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能,可增加磁盘。注意:一个Raid Disk实际有多个磁盘。


    Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。


    Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加,应小于磁盘设备最大容量。


     Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。


    Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。



Network Interface:


Bytes Total/sec :为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较

另:
 
1.        平均事务响应时间
Average Transation Response Time        优秀:<2s
良好:2-5s
及格:6-10s
不及格:>10s
2.        每秒点击率
Hits per Second
当增大系统的压力(或增加并发用户数)时,吞吐率和TPS的变化曲线呈大体一致,则系统基本稳定若压力增大时,吞吐率的曲线增加到一定程度后出现变化缓慢,甚至平坦,很可能是网络出现带宽瓶颈.同理若点击率/TPS曲线出现变化缓慢或者平坦,说明服务器开始出现.
3.        请求响应时间
Time to Last Byte      
4.        每秒系统处理事务数
Transaction per second      
5.        吞吐量
Throughout      
6.        CPU利用率
Processor / %Processor Time        好:70%
坏:85%
很差:90%+
7.        数据库操作消耗的CPU时间
Processor / %User Time        如果该值较大,可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器, Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间,此时可以考虑对数据库系统进行优化。
8.        核心态CPU平均利用率
Processor /%Privileged Time        如果该参数值和"Physical Disk"参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统
9.        处理列队中的线程数
Processor / Processor Queue Length        如果该值保持不变(>=2)个并且%Processor Time 超过90%,那么可能存在处理器瓶颈。如果发现超过2,而处理器的利用率却一直很低,那么或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈。
10.        文件系统缓存
Memory / Cache Bytes        50%的可用物理内存
11.        剩余的可用内存
Memory  / Avaiable Mbytes        至少要有10% 的物理内存值
12.        每秒下载页数
Memory  / pages/sec        好:无页交换
坏:CPU每秒10个页交换
很差:更多的页交换
13.        页面读取操作速率
Memory  / page read/sec        如果页面读取操作速率很低,同时 % Disk Time 和 Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。
14.        物理磁盘利用率
Physical Disk / %Disk Time        好:<30%
坏:<40%
很差:<50%+
15.        物理磁盘平均磁盘I/O队列长度
Physical Disk / Avg.Disk Queue Length        该值应不超过磁盘数的1.5~2 倍。要提高性能,可增加磁盘
16.        网络吞吐量
Network Interface / Bytes Total/sec        判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽,结果应该小于50%
17.        数据高速缓存区命中率        命中率应大于0.90最好
18.        共享区库缓存区命中率        命中率应大于0.99
19.        监控 SGA 中字典缓冲区的命中率        命中率应大于0.85
20.        检测回滚段的争用        小于1%
21.        监控 SGA 中重做日志缓存区的命中率
应该小于1%
22.        监控内存和硬盘的排序比率        最好使它小于 10%

TAG:

 

评分:0

我来说两句

Open Toolbar