[精品]经验总结.doc

精品经验总结 大家好，今后，我们将以专题的方式展开对LR监视的性能计数器及LR的场景设计设计的讨论，欢迎大家涌跃发言。 今天，我先把我的一些计数器及其阈值要求等贴出来，这些计数器是针对我对windows操作系统，C/S结构的sql server数据库及WEB平台.产品测试时的一些计数器；大家可以继续补充，作过unix平台上oracle数据库测试及J2EE架构及WEBLOGIC方面测试的朋友，也希望把自己使用的计数器贴出来，让大家分享。 好了，先说这些了，希望通过这个专题，最终能让大家对自己的测试结果进行分析。 Memory:内存使用情况可能是系统性能中最重要的因素。 如果系统“页交换”频繁，说明内存不足。 “页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从RAM移动到磁盘的过程，其目的是为了释放内存空间。 尽管某些页交换使Windows2000能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。 减少页交换将显著提高系统响应速度。 要监视内存不足的状况，请从以下的对象计数器开始Available Mbytes:可用物理内存数.如果Available Mbytes的值很小（4MB或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。 page/sec:表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。 一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。 有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。 Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。 page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。 阈值为5.越低越好。 大数值表示磁盘读而不是缓存读。 由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。 因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器Physical Disk%Disk TimePhysical DiskAvg.Disk Queue Length例如，包括Page Reads/sec和%Disk Time及Avg.Disk QueueLength。 如果页面读取操作速率很低，同时%Disk Time和Avg.Disk QueueLength的值很高，则可能有磁盘瓶径。 但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。 要确定过多的页交换对磁盘活动的影响，请将Physical DiskAvg.Disk sec/Transfer和MemoryPages/sec计数器的值增大数倍。 如果这些计数器的计数结果超过了0.1，那么页交换将花费百分之十以上的磁盘访问时间。 如果长时间发生这种情况，那么您可能需要更多的内存。 Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。 Cache Bytes文件系统缓存（File SystemCache），默认情况下为50%的可用物理内存。 如IIS5.0运行内存不够时，它会自动缓存。 需要关注该计数器的趋势变化如果您怀疑有内存泄露，请监视MemoryAvailable Bytes和MemoryCommitted Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的ProcessPrivate Bytes、ProcessWorking Set和ProcessHandle Count。 如果您怀疑是内核模式进程导致了泄露，则还应该监视MemoryPool NonpagedBytes、MemoryPool NonpagedAllocs和Process(process_name)Pool NonpagedBytes。 Pages persecond:每秒钟检索的页数。 该数字应少于每秒一页。 Process%Processor Time:被处理器消耗的处理器时间数量。 如果服务器专用于sql server,可接受的最大上限是80-85%Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。 Work set:处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。 如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。 Iinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。 如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。 Processor监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。 %Processor Time:如果该值持续超过95%，表明瓶颈是CPU。 可以考虑增加一个处理器或换一个更快的处理器。 %User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。 如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 %Privileged Time（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。 如果该参数值和Physical Disk参数值一直很高，表明I/O有问题。 可考虑更换更快的硬盘系统。 另外设置Tempdb inRAM，减低max asyncIO，max lazywriter IO等措施都会降低该值。 此外，跟踪计算机的服务器工作队列当前长度的Server WorkQueuesQueueLength计数器会显示出处理器瓶颈。 队列长度持续大于4则表示可能出现处理器拥塞。 此计数器是特定时间的值，而不是一段时间的平均值。 %DPC Time:越低越好。 在多处理器系统中，如果这个值大于50%并且Processor:%Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。 Thread ContextSwitches/sec:(实例化iinfo和dllhost进程)如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。 增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。 如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。 Physical Disk:%Disk Time%:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。 如果三个计数器都比较大，那么硬盘不是瓶颈。 如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。 在记录该计数器之前，请在Windows2000的命令行窗口中运行diskperf-yD。 若数值持续超过80%，则可能是内存泄漏。 Avg.Disk QueueLength:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。 该值应不超过磁盘数的1.52倍。 要提高性能，可增加磁盘。 注意一个Raid Disk实际有多个磁盘。 Average DiskRead/Write QueueLength:指读取(写入)请求(列队)的平均数。 Disk Reads(Writes)/s:物理磁盘上每秒钟磁盘读、写的次数。 两者相加，应小于磁盘设备最大容量。 Average Disksec/Read:指以秒计算的在此盘上读取数据的所需平均时间。 Average Disksec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。 Network InterfaceBytes Total/sec:为发送和接收字节的速率，包括帧字符在内。 判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较SQLServer性能计数器Aess Methods(访问方法)用于监视访问数据库中的逻辑页的方法。 .Full Scans/sec(全表扫描/秒)每秒不受限的完全扫描数。 可以是基本表扫描或全索引扫描。 如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及S QL查询是否可以被优化。 .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语句以及触发器。 .CacheHitRatio(高速缓存命中率，所有Cache”的命中率。 在SQL Server中，Cache可以包括Log Cache，Buffer Cache以及Procedure Cache，是一个总体的比率。 )高速缓存命中次数和查找次数的比率。 对于查看SQL Server高速缓存对于你的系统如何有效，这是一个非常好的计数器。 如果这个值很低，持续低于80%，就需要增加更多的内存。 Latches(闩)用于监视称为闩锁的内部SQL Server资源锁。 监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。 .Average LatchWait Tim e(m s)(平均闩等待时间(毫秒)一个SQL Server线程必须等待一个闩的平均时间，以毫秒为单位。 如果这个值很高，你可能正经历严重的竞争问题。 .Latch Waits/sec(闩等待/秒)在闩上每秒的等待数量。 如果这个值很高，表明你正经历对资源的大量竞争。 Locks(锁)提供有关个别资源类型上的SQL Server锁的信息。 锁加在SQL Server资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。 例如，如果一个排它(X)锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。 尽可能少使用锁可提高并发性，从而改善性能。 可以同时监视Locks对象的多个实例，每个实例代表一个资源类型上的一个锁。 .Number ofDeadlocks/sec(死锁的数量/秒)导致死锁的锁请求的数量.Average WaitTime(ms)(平均等待时间(毫秒)线程等待某种类型的锁的平均等待时间.Lock Requests/sec(锁请求/秒)每秒钟某种类型的锁请求的数量。 Memory manager:用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。 监视SQL Server实例所使用的内存有助于确定是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。 如果是这样，SQL Server必须从磁盘检索数据。 是否可以通过添加更多内存或使更多内存可用于数据高速缓存或SQL Server内部结构来提高查询性能。 Lock blocks:服务器上锁定块的数量，锁是在页、行或者表这样的资源上。 不希望看到一个增长的值。 Total servermemory sqlserver服务器当前正在使用的动态内存总量.监视IIS需要的一些计数器Inter InformationServices Global:File Cache Hits%、File CacheFlushes、File CacheHits File CacheHits%是全部缓存请求中缓存命中次数所占的比例，反映了IIS的文件缓存设置的工作情况。 对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。 而File CacheHits是文件缓存命中的具体值，File CacheFlushes是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。 通过比较File CacheHits和FileCacheFlushes可得出缓存命中率对缓存清空率的比率。 通过观察它两个的值，可以得到一个适当的刷新值（参考IIS的设置ObjectTTL、MemCacheSize、MaxCacheFileSize）Web Service:Bytes Total/sec:显示Web服务器发送和接受的总字节数。 低数值表明该IIS正在以较低的速度进行数据传输。 Connection Refused数值越低越好。 高数值表明网络适配器或处理器存在瓶颈。 Not FoundErrors显示由于被请求文件无法找到而无法由服务器满足的请求数（状态代码404）LoadRunner学习笔记积累（五）LoadRunner学习笔记积累（五）次系列主要是名词方面的解释迭代（Iterate）设计，或者我们称之为增量（Incremental）设计的思想和XP提倡的Evolutionary Design有异曲同工之妙。 注意 1、参数类型在创建参数的时候，我选择了参数类型为File。 参数类型共有9种，现在来简单介绍一下所有的参数类型以及意义。 1. 1、DateTime在需要输入日期/时间的地方，可以用DateTime类型来替代。 其属性设置也很简单，选择一种格式即可。 当然也可以定制格式。 1. 2、Group Name很少用到。 在实际运行中，LoadRunner使用该虚拟用户所在的Vuser Group来代替。 但是在VuGen中运行时，Group Name将会是None。 1. 3、Load GeneratorName在实际运行中，LoadRunner使用该虚拟用户所在LoadGenerator的机器名来代替。 1. 4、Iteration Number在实际运行中，LoadRunner使用该测试脚本当前循环的次数来代替。 1. 5、Random Number随机数。 很简单。 在属性设置中可以设置产生随机数的范围。 1. 6、Unique Number唯一的数。 在属性设置中可以设置第一个数以及递增的数的大小。 注意使用该参数类型必须注意可以接受的最大数。 例如某个文本框能接受的最大数为99。 当使用该参数类型时，设置第一个数为1，递增的数为1，但100个虚拟用户同时运行时，第100个虚拟用户输入的将是100，这样脚本运行将会出错。 这里说的递增意思是各个用户取第一个值的递增数，每个用户相邻的两次循环之间的差值为1。 举例说明假如起始数为1，递增为5，那么第一个用户第一次循环取值1，第二次循环取值2；第二个用户第一次循环取值为6，第二次为7；依次类推。 1. 7、Vuser ID设置比较简单。 在实际运行中，LoadRunner使用该虚拟用户的ID来代替，该ID是由Controller来控制的。 但是在VuGen中运行时，Vuser ID将会是1。 1. 8、File需要在属性设置中文件，添加内容，也可以从现成的数据库中取数据1. 9、User DefinedFunction从用户开发的dll文件提取数据。 LoadRunner学习笔记积累（七）回到增加Oracle资源监视器页面中，点击资源度量区域内的添加按钮。 弹出一个Oracle登录窗口，输入对应实例的“登录名”、“密码”和“服务器名”（这里应该是“服务名”，中文包翻译出错）。 点击确定，如果输入正确的话能够成功打开Oracle各项度量和实例的列表，可根据需要选择监控的对象。 需要注意的是，这里的“服务器名”是指本地Oracle的tnsnames.ora文件