|
知识路径: > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 > 结果评估与测试报告 >
|
考试要求:掌握
相关知识点:25个
|
|
|
|
资源占用主要涉及服务器操作系统资源占用、数据库资源占用、中间件资源占用等内容,下面分别论述。
|
|
|
|
通过《负载压力测试指标》章节的讨论,可以将服务器操作系统资源占用监控指标概括为以下几个方面:
|
|
|
|
|
|
|
|
|
|
|
. Memory:内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁,说明内存不足。“页交换”是使用称为“页面”的单位,将固定大小的代码和数据块从RAM移动到磁盘的过程,其目的是为了释放内存空间。尽管某些页交换使Windows 2000能够使用比实际更多的内存,也是可以接受的,但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况,请从以下的对象计数器开始。
|
|
|
①Available Mbytes:可用物理内存数。如果Available Mbytes的值很小(4MB或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
|
|
|
②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,那么页交换将花费10%以上的磁盘访问时间。如果长时间发生这种情况,那么可能需要更多的内存。
|
|
|
. Page Faults/sec:每秒钟软性页面失效的数目(包括有些可以直接在内存中满足而有些需要从硬盘读取),而page/sec只表明数据不能在指定内存中立即使用。
|
|
|
. Cache Bytes:文件系统缓存(File System Cache),默认情况下为50%的可用物理内存。如果怀疑有内存泄露,请监视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:每秒钟检索的页数。该数字应少于每秒1页。
|
|
|
. 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 I/O”等措施都会降低该值。此外,跟踪计算机的服务器工作队列当前长度的Server Work Queues\ Queue Length计数器会显示出处理器瓶颈。队列长度持续大于4,则表示可能出现处理器拥塞。此计数器是特定时间的值,而不是一段时间的平均值。
|
|
|
. %DPC Time:越低越好。在多处理器系统中,如果这个值大于50%并且“Processor:%Processor Time”非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。
|
|
|
. Context Switches/sec:如果决定要增加线程字节池的大小,应该同时监视实例化inetinfo和dllhost进程这两个计数器。增加线程数可能会增加上下文切换次数,这样性能不会上升,反而下降。如果多个实例的上下文切换值非常高,就应该减小线程字节池的大小。
|
|
|
. %Disk Time:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果只有%Disk Time比较大,而CPU和内存都比较适中,硬盘可能会是瓶颈。
|
|
|
. 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:指以秒计算的在此盘上写入数据的所需平均时间。.Bytes Total/sec:为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽进行比较。
|
|
|
|
通过《负载压力测试指标》章节的讨论,可以将数据库资源占用监控指标概括为:
|
|
|
|
|
|
. 共享内存中物理日志和逻辑日志的缓冲区的使用率。
|
|
|
. 磁盘的数据块使用情况以及被频繁读写的热点区域。
|
|
|
|
|
|
|
下面以SQL Server数据库性能计数器为例来分析。
|
|
|
. Access Methods:用于监视数据库逻辑页访问方法。
|
|
|
. Full Scans/sec:每秒钟不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高,应该分析查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
|
|
|
. Page splits/sec:由于数据更新操作引起的每秒页分割的数量。
|
|
|
. Buffer Manager:监视SQL Server如何使用内存存储数据页、内部数据结构和过程高速缓存。计数器在SQL Server从磁盘读取数据库页和将数据库页写入磁盘时监视物理I/O。监视SQL Server所使用的内存和计数器,有助于确定是否由于缺少可用物理内存存储高速缓存中经常访问的数据,而导致瓶颈存在。如果是这样,SQL Server必须从磁盘检索数据,以及考虑是否可通过添加更多内存,或使更多内存可用于数据高速缓存或SQL Server内部结构来提高查询性能。
|
|
|
. Disk I/O: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:对象提供计数器,用于监视SQL Server如何使用内存存储对象,如存储过程、特殊和准备好的Transact-SQL语句以及触发器。
|
|
|
. Cache Hit Ratio:Cache可以包括Log Cache, Buffer Cache以及Procedure Cache,是一个总体的比率,是高速缓存命中次数和查找次数的比率之和。其对查看SQL Server高速缓存对于系统性能提升如何有效,是一个非常好的计数器。如果这个值持续低于80%,就需要增加更多的内存。
|
|
|
. Latches:用于监视称为“闩锁”的内部SQL Server资源锁。监视闩锁以明确用户活动和资源使用情况,有助于查明性能瓶颈。
|
|
|
. Average Latch Wait Time(ms):一个SQL Server线程必须等待一个闩的平均时间,以毫秒为单位。如果这个值很高,系统可能正经历严重的竞争问题。
|
|
|
. Latch Waits/sec:在闩上每秒的等待数量。如果这个值很高,表明系统正经历严重的竞争问题。
|
|
|
. Locks:提供有关个别资源类型上的SQL Server锁的信息。锁加在SQL Server资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。例如,如果一个排它锁被一个事务加在某一表的某一行上,在这个锁被释放前,其他事务都不可以修改这一行。应尽可能少使用锁,可提高并发性,从而改善性能。可以同时监视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服务器当前正在使用的动态内存总量。
|
|
|
|
|
|
|
|
|
|
. %File Cache Hits:是全部缓存请求中缓存命中次数所占的比例,反映了IIS的文件缓存设置的工作情况。对于一个由大部分静态网页组成的网站,该值应该保持在80%左右。File Cache Hits是文件缓存命中的具体值,而File CacheFlushes是自服务器启动之后文件缓存刷新次数,如果刷新得太慢,会浪费内存;如果刷新得太快,缓存中的对象会太频繁地丢弃生成,起不到缓存的作用。通过比较File Cache Hits和File Cache Flushes可得出缓存命中率与缓存清空率的比率。通过观察这两个值,可以得到一个适当的刷新值(参考IIS的ObjectTTL、MemCacheSize和MaxCacheFileSize设置)。
|
|
|
|
①Bytes Total/sec:显示Web服务器发送和接收的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
|
|
|
②Connection Refused:数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
|
|
|
③Not Found Errors:显示由于被请求文件无法找到而导致的服务器无法回应的请求数(HTTP状态代码404)。
|
|
|