LoadRunner监视的性能计数器

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
简介:
大家好,今后,我们将以专题的方式展开对 LR 监视的性能计数器及 LR 的场景设计设计的讨论,欢迎大家涌跃发言。  
今天,我先把我整理的一些计数器及其阈值要求等贴出来,这些计数器是针对我对 windows 操作系统, C/S 结构的 sql server 数据库及 WEB 平台 .net 产品测试时的一些计数器;大家可以继续补充,作过 unix 平台上 oracle 数据库测试及 J2EE 架构及 WEBLOGIC 方面测试的朋友,也希望把自己使用的计数器贴出来,让大家分享。  
好了,先说这些了,希望通过这个专题,最终能让大家对自己的测试结果进行分析。
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 :
为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较
SQLServer 性能计数器:  
Access Methods(
访问方法 用于监视访问数据库中的逻辑页的方法。  
. Full Scans/sec(
全表扫描 / 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比 1 2 高,应该分析你的查询以确定是否确实需要全表扫描,以及 S Q L 查询是否可以被优化。  
. Page splits/sec(
页分割 / ) 由于数据更新操作引起的每秒页分割的数量。  
Buffer Manager(
缓冲器管理器 ) :监视  Microsoft® SQL Server?  如何使用:   内存存储数据页、内部数据结构和过程高速缓存;计数器在  SQL Server  从磁盘读取数据库页和将数据库页写入磁盘时监视物理  I/O   监视  SQL Server  所使用的内存和计数器有助于确定:   是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样, SQL Server  必须从磁盘检索数据。   是否可通过添加更多内存或使更多内存可用于数据高速缓存或  SQL Server  内部结构来提高查询性能。  
SQL Server 
需要从磁盘读取数据的频率。与其它操作相比,例如内存访问,物理  I/O  会耗费大量时间。尽可能减少物理  I/O  可以提高查询性能。  
.Page Reads/sec
:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理  I/O  的开销大,可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,使开销减到最小。  
.Page Writes/sec (.
写的页 / 每秒执行的物理数据库写的页数。  
.Buffer Cache Hit Ratio. 
缓冲池 Buffer Cache/Buffer Pool )中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自  SQL Server  实例启动后对高速缓存的查找总数。经过很长时间后,这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多,一般希望这一数值高一些。通常,可以通过增加  SQL Server  可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定,但比率最好为 90%  或更高。增加内存直到这一数值持续高于 90% ,表示 90%  以上的数据请求可以从数据缓冲区中获得所需数据。  
. Lazy Writes/sec(
惰性写 / ) 惰性写进程每秒写的缓冲区的数量。值最好为 0  
Cache Manager(
高速缓存管理器 对象提供计数器,用于监视  Microsoft® SQL Server?  如何使用内存存储对象,如存储过程、特殊和准备好的  Transact-SQL  语句以及触发器。  
. Cache Hit Ratio(
高速缓存命中率,所有 Cache” 的命中率。在 SQL Server 中, Cache 可以包括 Log Cache Buffer Cache 以及 Procedure Cache ,是一个总体的比率。 高速缓存命中次数和查找次数的比率。对于查看 SQL Server 高速缓存对于你的系统如何有效,这是一个非常好的计数器。如果这个值很低,持续低于 80% ,就需要增加更多的内存。  
Latches(
用于监视称为闩锁的内部  SQL Server  资源锁。监视闩锁以明确用户活动和资源使用情况,有助于查明性能瓶颈。  
. Average Latch Wait Ti m e ( m s ) (
平均闩等待时间 ( 毫秒 ))  一个 SQL Server 线程必须等待一个闩的平均时间,以毫秒为单位。如果这个值很高,你可能正经历严重的竞争问题。  
. Latch Waits/sec (
闩等待 / 在闩上每秒的等待数量。如果这个值很高,表明你正经历对资源的大量竞争。  
Locks(
提供有关个别资源类型上的  SQL Server  锁的信息。锁加在  SQL Server  资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。例如,如果一个排它  (X)  锁被一个事务加在某一表的某一行上,在这个锁被释放前,其它事务都不可以修改这一行。尽可能少使用锁可提高并发性,从而改善性能。可以同时监视  Locks  对象的多个实例,每个实例代表一个资源类型上的一个锁。  
. Number of Deadlocks/sec(
死锁的数量 / 导致死锁的锁请求的数量  
. Average Wait Time(ms) (
平均等待时间 ( 毫秒 ))  线程等待某种类型的锁的平均等待时间  
. Lock Requests/sec(
锁请求 / 每秒钟某种类型的锁请求的数量。  
Memory manager:
用于监视总体的服务器内存使用情况,以估计用户活动和资源使用,有助于查明性能瓶颈。监视  SQL Server  实例所使用的内存有助于确定:  
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样, SQL Server  必须从磁盘检索数据。  
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或  SQL Server  内部结构来提高查询性能。  
Lock blocks:
服务器上锁定块的数量,锁是在页、行或者表这样的资源上。不希望看到一个增长的值。  
Total server memory
sql server 服务器当前正在使用的动态内存总量 .
监视 IIS 需要的一些计数器  
Internet Information Services Global: 
File Cache Hits %
File CacheFlushes File Cache Hits 
File Cache Hits %
是全部缓存请求中缓存命中次数所占的比例,反映了 IIS  的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站,该值应该保持在 80% 左右。而 File Cache Hits 是文件缓存命中的具体值, File CacheFlushes  是自服务器启动之后文件缓存刷新次数,如果刷新太慢,会浪费内存;如果刷新太快,缓存中的对象会太频繁的丢弃生成,起不到缓存的作用。通过比较 File Cache Hits  File Cache Flushes  可得出缓存命中率对缓存清空率的比率。通过观察它两个的值,可以得到一个适当的刷新值(参考 IIS  的设置 ObjectTTL  MemCacheSize  MaxCacheFileSize  
Web Service: 
Bytes Total/sec:
显示 Web 服务器发送和接受的总字节数。低数值表明该 IIS 正在以较低的速度进行数据传输。  
Connection Refused
:数值越低越好。高数值表明网络适配器或处理器存在瓶颈。  
Not Found Errors
:显示由于被请求文件无法找到而无法由服务器满足的请求数( HTTP 状态代码 404




本文转自 fish_yy 51CTO博客,原文链接:http://blog.51cto.com/tester2test/139331,如需转载请自行联系原作者
相关实践学习
使用SQL语句管理索引
本次实验主要介绍如何在RDS-SQLServer数据库中,使用SQL语句管理索引。
SQL Server on Linux入门教程
SQL Server数据库一直只提供Windows下的版本。2016年微软宣布推出可运行在Linux系统下的SQL Server数据库,该版本目前还是早期预览版本。本课程主要介绍SQLServer On Linux的基本知识。 相关的阿里云产品:云数据库RDS SQL Server版 RDS SQL Server不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的License费用,减少额外支出。 了解产品详情: https://www.aliyun.com/product/rds/sqlserver
目录
相关文章
|
监控 算法 Linux
【C/C++ 实用工具】CPU使用率监控工具对比
【C/C++ 实用工具】CPU使用率监控工具对比
37 0
|
7月前
|
C++ Windows
使用 windbg gflags dumpbin 排查应用程序启动错误
使用 windbg gflags dumpbin 排查应用程序启动错误
|
8月前
|
监控 小程序
利用PowerShell写的一个CPU监控小程序
业务部门需要,所以写的一个CPU监控小程序,有窗口显示,同时会在当前目录生成日志,有需要的自取,复制代码,TXT另存为xx.ps1即可。 仅供学习交流。
125 0
|
监控 Windows
如何用Windows性能监视器进行SMB性能监控和分析
本文介绍如何通过Windows 性能监视器(Perfmon) 使用SMB 客户端性能计数器(Performance Counters)进行性能监控和分析。
3177 0
|
监控 Unix Linux
LoadRunner监控Unix、Windows方法及常用性能指标
目  录 一、LoadRunner监控Linux资源.... 3 (一)、准备工作... 3 1、可以通过两种方法验证服务器上是否配置了rstatd守护程序:... 3 (2)使用find命令.
1895 0