如何使用Loadrunner进行资源占用率的分析？（08-12-29）（获奖名单已公布）
Loadrunner作为业界最流行的性能测试工具，应用已经十分广泛。Loadrunner如何分析性能数据，这个是每一个做性能测试人员都非常关心的话题．但此话题受具体业务和环境的影响不太好回答，所以缩小一下范围．如何使用Loadrunner进行资源占用率（CPU，内存，硬盘）的分析？
感谢会员wichingh提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖archonwang当当购物卡50元5#二等奖fmsbai5300论坛积分15#三等奖angelna100论坛积分 23#
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
相关文章：
深入理解LoadRunner测试结果
LoadRunner学习——LoadRunner的安装
LoadRunner函数介绍
LoadRunner性能测试经验总结
LoadRunner监控Windows和Linux常见问题
更多内容请点击＞＞＞
这个问题有难度啊。 个人觉得CPU、内存、硬盘这些数据单单的去看可能看不出什么。要放在一起才好分析出问题。例如把这些数据还有相关的加压数。吞吐量,每秒点击率，等都放在一起看。看在什么样的情况下哪个指标过高或是出现异常, 占位:lol 情况比较复杂，有兴趣的话可以就这个问题写本很厚的书。
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: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical 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 :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较
[ 本帖最后由 archonwang 于 2008-12-30 13:48 编辑 ] 楼上的同学每次回答都很认真啊．
综合考虑为佳.
对呀,我也觉得应该综合考虑...不然,实在是不容易呀..哈哈..:lol 斑竹出售 果然不同凡响 5楼的说的很全面，想请教一下，用loadrunner监控 linux的话，只有statd里的一些计数器，可能对分析问题还不够，有没有更好的方法监控更多的计数器。 并发性能测试的测试内容如下:一、负载压力测试。模拟不同数量用户并发执行关键业务，测试系统能够承受的最大并发用户数。
二、系统资源监控。进行负载压力测试的同时，使用测试工具监控数据库服务器、应用服务器以及中间件服务的资源占用情况。观察不同压力下，各服务器资源占用变化曲线，找出系统的性能瓶颈。
性能测试中除需要选择正确的性能测试点和测试策略外，测试环境也是关系性能测试能否成功的关键因素。
通常，性能测试需要在测试环境中进行，所以要求测试环境尽量同生产环境保持一致．
在建立好测试环境后，接下来就要准备测试案例。测试案例的选取有三点:第一、根据系统实际的用户数量制定并发用户;第二、根据系统的关键业务流程点;第三、根据系统在某个时段可能产生最大的并发量。
根据以上几点方法，测试人员与开发人员进行充分沟通后，分析可能出现的压力、设计出单项并发测试案例和疲劳测试案例。 羡慕懂性能测试的同行，继续努力，向你们学习哦！ 以我目前的水平还是先不要误人子弟了，先顶下5楼的！！ 我赞同 综合考虑
谢谢楼主 12楼的讲话比较到位！
顶一个 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%
恩,这个问题很深,要考虑的问题很多.
刚开始还在监控器里面添加一些记数器的,后来发现加了自己也看不明白就不加了.:lol ,我想请教一个问题LR里面带宽的选择基本上可以模拟你所在的测试环境么?外网就用速度低的.内部就用速度高的,仅次而已? 原帖由 leaveall 于 2009-1-6 16:01 发表 http://bbs.51testing.com/images/common/back.gif
刚开始还在监控器里面添加一些记数器的,后来发现加了自己也看不明白就不加了.
:lol ,我想请教一个问题LR里面带宽的选择基本上可以模拟你所在的测试环境么?外网就用速度低的.内部就用速度高的,仅次而已?
问题中又见问题呀 占位，上来学习下
回复 16# 的帖子
关于带宽限制，我们一般都会考虑服务器的可供应带宽来考量。如果说需要测试客户端压力也可以使用该选项。 来学习一下，刚刚接触
页:
[1]
2
