Windows IIS SQLServer性能测试有关计数器监视及相应的分析方法@

有关windows资源计数器：

相应的分析方法：

一、内存

1、查看Available MBytes (memory)。

可用物理内存数。一般要保留10%的可用内存。最低不能<4M，此值过小可能是内存不足或内存泄漏。

2、查看page faults/sec(memory)、pages input/sec(memory)及page reads/sec(memory)。

如果有个程序请求内存中的一页，但系统无法在所需的位置上找到它，就会构成一个分页错误。如果此页位于内存中的其它位置，则此错误便称为软件分页错误。如果必须从磁盘获取此页，则此错误便称为硬件分页错误。大部分的处理器可以处理大量的软件错误而不会引起任何后果。但是，硬件错误却会导致严重的延迟。

「page faults/sec」是指处理器处理错误页 (包括硬件及软件分页错误) 的整体速度。「pages input/sec」是指为了解决硬件分页错误而从磁盘读取的总页数。

「pages reads/sec」是指为了解决硬件分页错误而读取磁盘的次数。

「pages input/sec」会大于或等于「page reads/sec」，并且能够清楚地让您了解硬件分页错误率。如果这些数字都很低，则服务器应该可以快速地响应请求。如果很高，则可能是因为您用了太多的内存在缓存处理上，而没有留足够的内存供系统的其它部份使用。可以增加内存或降低缓存的ram大小来解决。

详细：

page Faults/sec:只表明数据不能在内存的指定工作集中立即使用；

page Input/sec: page input/sec > page reads/sec;

page Reads/sec: 阈值为>5.越小越好,大数值表示磁盘读而不是缓存读；

Page/sec：指为解析硬页错误从磁盘读取或写入磁盘的页数(是Pages Input/sec 和 Pages Output/sec 的总和)。其值推荐00-20如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题(太多的读写数据操作要访问磁盘，可考虑增加内存或优化读写数据的算法)，如果值比较低，说明Web 服务器响应请求比较快，否则可能是服务器系统内存短缺引起（也可能是缓存太大，导致系统内存太少）。

3、查看Pool Nonpaged Bytes（Memory）计数器的值。

Pool Nonpaged Bytes 指在非分页池中的字节数，非分页池是指系统内存(操作系统使用的物理内存)中可供对象(指那些在不处于使用时不可以写入磁盘上而且只要分派过就必须保留在物理内存中的对象)使用的一个区域。缓慢增长表示存在内存泄漏问题。

二、处理器

1、%processor time（processor）、%user time（processor）、%privileged time（processor）

% Processor Time 指处理器执行非闲置线程时间的百分比;通俗一点讲就是CPU 使用率。这是监视处理器活动的主要指示器。它通过在每个范例间隔中衡量处理器用于执行闲置处理线程的时间，并且用100%减去该值得出。(每台处理器有一个闲置线程，该线程在没有其它线程可以运行时消耗周期)。可将其视为范例间隔用于做有用工作的百分比。

正常值<90，此值过大表示处理器的性能已经不能应付程序的要求，要换更快的处理器。该数值持续超过 90%，则表示此测试的负载对于目前的硬件过于沉重。排除内存因素，如果该计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU瓶颈。

% User Time 指处理器处于用户模式的时间百分比。如果该值较大，说明应用程序或数据库需要进行优化。

% Privileged Time 是在特权模式下处理线程执行代码所花时间的百分比。

2、processor queue length（system）

Processor Queue Length：是指处理列队中的线程数。显示在由 Web服务器所有处理器共享的队列中等待执行的线程数。如果处理器列队中总是有2个以上的线程通常表示处理器堵塞。

参考值：小于2。处理器瓶颈会导致该值持续大于 2。

三、网络

1、bytes total/sec（network interface）。

若要判定您的网络连接是否正在存在瓶颈，请比较「network interface: bytes total/sec」计数器与您的网络适配卡总带宽。若要在传送量中留些空间供尖峰时间用，则不应常使用超过 50% 的容量。如果这个数字十分接近连接的容量，而处理器及内存的使用都很适中，则此连接也会是个问题。

四、磁盘

1、% processor time（processor）,bytes total/sec（network interface connection）及% disk time（physicaldisk）。

Physical Disk\ % Disk Time 、Physical Disk\ Avg.Disk Queue Length 、Memory\ Pages/sec(结果分析方法资料收集.doc)有不同说法。

%Disk Time %: 指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。

如果这三个计数器的值都很高，则硬盘不会引起站点的瓶颈。但是，如果「% disk time」的值很高，但处理器及网络连接并没有饱和，则硬盘可能会造成瓶颈。如果在您的服务器上没有启用「physical disk」计数器，请在Windows 2000 的命令行窗口中运行diskperf -yD。正常值<10，此值过大表示耗费太多时间来访问磁盘，可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和)，则可能是

内存泄漏。

2、Avg. Disk Queue Length、Page Reads/sec

指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。正常值<0.5，此值过大表示磁盘IO太慢，要更换更快的硬盘。

Disk Transfers/sec 指在此盘上读取/写入操作速率。正常值<(Disk Bytes/sec)/3，此值过大表示系统要求的IO速度已接近硬盘的最大速度，要更换更快的硬盘。

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

有关IIS应用服务器计数器：

与性能有关系的参数调整：

1、查看requests/sec、requests executing、request wait time、request executing time、requests queued（active server pages）。

「active server pages︰requests/sec」不含静态文件或其它动态内容的请求，它会根据 asp 网页的复杂度及您 web 服务器的容量明显地变动。

如果这个计数器在服务器上的传输量处于尖峰期间出现低值的话，则您的应用程序可能会导致瓶颈。

「requests executing」显示目前正在执行的请求数目；「request wait time」显示最近的请求在队列中等待的毫秒数；「request execution time」显示最近的请求花在执行上的毫秒数。

理想的状态是「requests queued 」及「request wait time」应保持接近 0，但它们会在不同的载量下起伏变动。最大「requests queued」数目是由 asprequestqueuemax 的metabase 设置来决定。

如果达到此限制，则客户端浏览器将显示 [http 500/ 服务器太过忙碌]。此时，若请求的执行时间「request execution time」很短，而且在队列中的时间「request wait time」很短，则可以考虑增加asprequestqueuemax限制值（默认请求限制3000个）。

（如果「requests executing」、「requests queued」都较小，而CPU的使用率较高，则可以减小aspprocessorthreadmax的值，看一下性能是否有所提高）

如果这些数字大幅偏离了预计的范围，则您的 asp 应用程序可能必须重写才能提高性能。如果「requests executing」的值是高的、「requests queued」是大的，而CPU的使用率是较低的，则可能必须增加 aspprocessorthreadmax。

2、查看Requests Queued（https://www.360docs.net/doc/8b2387484.html,）计数器的值。

队列中等待服务的请求的数目。当该数开始随客户端负载线性增加时，Web 服务器计算机已达到能同时处理的请求数的上限。该数的默认最大值为 5,000。

若达到最大值，可以在计算机的 Machine.config 文件中更改此设置。

3、查看page faults/sec(memory)、pages input/sec(memory)及page reads/sec(memory)。

如果有个程序请求内存中的一页，但系统无法在所需的位置上找到它，就会构成一个分页错误。如果此页位于内存中的其它位置，则此错误便称为软件分页错误。如果必须从磁盘

获取此页，则此错误便称为硬件分页错误。大部分的处理器可以处理大量的软件错误而不会引起任何后果。但是，硬件错误却会导致严重的延迟。

「page faults/sec」是指处理器处理错误页 (包括硬件及软件分页错误) 的整体速度。「pages input/sec」是指为了解决硬件分页错误而从磁盘读取的总页数。

「pages reads/sec」是指为了解决硬件分页错误而读取磁盘的次数。

「pages input/sec」会大于或等于「page reads/sec」，并且能够清楚地让您了解硬件分页错误率。

如果这些数字都很低，则服务器应该可以快速地响应请求。如果很高，则可能是因为您用了太多的内存在缓存处理上，而没有留足够的内存供系统的其它部份使用。您可能必须在服务器上添加 ram 的容量，但是降低缓存的大小也是可行的。

4、查看cache bytes(memory)、file cache hits %(internet information services global)、file cache flushes(internet information services global)，及file cache hits(internet information services global)。

第一个计数器「memory : cache bytes」显示「文件系统缓存」的大小，其默认为最多使用 50% 的可用物理内存。由于当缓存的内存快要不足时，iis 会自动调整它，所以请留意这个计数器行进的方向。

第二个计数器是缓存存取次数与缓存请求总数的比例，它会反应出此「iis 文件缓存」的设置表现的好不好。对于主要由静态文件组成的网站来说，80% 以上的缓存存取次数应是个不错的数字。

请比较最后两个计数器的记录文件「iis global: file cache flushes」（自服务器启动后的文件缓存刷新数）及「iis global︰file cache hits」（文件缓存中查找成功的总数），以判定您是否正以适当的速度将对象从您的缓存清除。如果清除发生太快，则对象可能会比其应有的频率更常从缓存中清除出来。如果清除发生太慢，就会浪费内存。请参阅中关于objectcachettl、memcachesize及maxcachedfilesize 对象的说明（通过调整iis metabase内容）。

5、context switch/sec:dllhost#n（thread）, context switchs/sec:inetinfo=>thread#（thread）,context switches/sec（system）。

如果决定增加线程缓冲池的大小，便应该监视这里列出的三个计数器。增加线程数目可能会增加内容切换的数目，因而造成性能不增反降。

每一个请求有 10 个或以上内容切换就已经是相当高的数字了；如果出现这些数字，请考虑降低线程缓冲池大小。想通过测量连接及请求来得出线程及整体性能之间的平衡点是不容易

的。每次当您调整线程时，请接着监视整体性能，以检查性能是增进还是降低。若要判定是否应该调整线程计数，请将进程中的每一个线程数目和处理器时间拿来和总处理器时间作比较。如果线程持续忙碌，但并没有使用全部的处理器时间，则建立更多线程对性能会有帮助。不过，如果所有线程都很忙，而且处理器已快接近最大容量，则最好将载量分配给更多服务器，而不要增加线程的数目。请参阅本文中〈附录 1︰性能设置〉的aspthreadgateenabled 及 aspprocessorthreadmax metabase 属性。

6、maximum connections（web service）及total connection attempts（web service）。

有关最大连接数。如果您正在计算机上执行的其他服务也使用网络连接，则应监视「web service: maximum connections」及「web service: total connection attempts」计数器，以检查您的web服务器是否能够尽可能地使用它需要的连接数目。请记得将这些数字与内存及处理器使用量作比较，如此才能确定连接就是问题，而不是其它组件有问题。

……

其它关于IIS的调优设置—

1、选用“HTTP压缩”，压缩文件、压缩静态文件。

2、connectiontimeout-这个属性会指定服务器在中断一条非使用中的连接之前，将等待的秒数。默认值是 900 (15 分钟)。因为开启的连接会降低性能，所以请考虑降低此值，并监视您的服务器在改变之后会有什么效果。

与程序设计、编码有关系的性能调整：

1、cgi requests/sec（web service）及isapi extension requests/sec（web servcie）。

会报告您的服务器是以哪个速度处理 cgi 及 isapi 应用程序请求。

如果这些值在负载增加时降低，则可能必须请求应用程序开发人员重新检查他们的程序代码。

2、Application Restarts、Worker Process Restarts（https://www.360docs.net/doc/8b2387484.html,）。

Application Restarts—应用程序重新启动的次数. Web 服务器的生存期中应用程序重新启动的次数。应用程序重新启动的次数随每次发生 Application_OnEnd 事件增加。由于Web.config 文件的更改、存储在应用程序 \bin 目录中的程序集的更改或者 Web 窗体页的过多更改，均可能导致发生应用程序重新启动。此计数器的意外增长可能意味着无法预料的问题正导致您的 Web 应用程序关闭。在这种情况下，应尽快进行调查。

Worker Process Restarts—辅助进程重新启动的次数。服务器计算机上辅助进程重新启动的次数。如果辅助进程意外地失败或者被有意地回收，则能够被重新启动。如果该计数器的值意外增加，应尽快进行调查。

注意:每次重新启动 Internet 信息服务 (IIS) 主机时都会重置该值。

3、看Errors Total（https://www.360docs.net/doc/8b2387484.html, Application）计数器的值。

错误总数。执行 HTTP 请求过程中发生的错误总数。包括所有分析器错误、编译错误或运行时错误。此计数器为 Errors During Compilation、Errors During Preprocessing 和Errors During Execution 计数器的总和。正常运行的 Web 服务器不应发生错误。如果https://www.360docs.net/doc/8b2387484.html, Web 应用程序中发生错误，它们可能会歪曲任何吞吐量结果，因为错误恢复的代码路径与原来的完全不一样。在性能测试前应调查并修复应用程序中的所有错误。

4、看Context Switches/sec（System）、%processor time（processor）计数器的值。

Context Switches/sec计数器测量 Web 服务器计算机中的所有 CPU 切换线程上下文的速率。此计数器的高数值通常说明存在高的锁争用，或是线程在用户模式与内核模式之间有大量切换。可能需要使用采样分析器和其他工具进一步研究。

如果系统的吞吐量降低并且CPU 的使用率很高，并且此现象发生时切换水平在15000 以上，那么意味着上下文切换次数过高。

5、查看Cache Total Turnover Rate（https://www.360docs.net/doc/8b2387484.html, Application）计数器的值。

Cache Total Turnover Rate高周转率可能说明存在问题。可能原因：缓存中有容易重新计算和很少使用的项或给缓存的项分配的有效期太短。

6、查看Pool Nonpaged Bytes（Memory）计数器的值。

Pool Nonpaged Bytes 指在非分页池中的字节数，非分页池是指系统内存(操作系统使用的物理内存)中可供对象(指那些在不处于使用时不可以写入磁盘上而且只要分派过就必须保留在物理内存中的对象)使用的一个区域。缓慢增长表示存在内存泄漏问题。

……

SQL SERVER数据库服务器计数器：

相应的分析方法：

有关参数调整：

1、首先看Available Kbytes计数器的值。

若可用内存不多（小于50兆），说明有其它应用程序抢占内存，此时可以考虑增大SQL SERVER的使用内存，看是否可以提升性能。

增大有关SQL SERVER使用内存方法：

a.通过调整属性，保留适量的可用内存，调整“SQL Server内存的最大值、最小值”，

可以增大最小可用内存。

b.增大“最小查询内存”；

c.如果物理内存大于4G，可以考虑启用AWE。

2、查看Committed Bytes计数器的值（使用的内存总数）

若大于物理内存，则可采用1的方法解决。

3、查看page file bytes : total(process)

若超过2倍的物理内存。解决方法同1。

4、查看Available Kbytes、全部页、目标页计数器的值。

Available Kbytes较小，且全部页已经接近目标页的值，则可以考虑将Buffer pool （sql server可用的内存）缩小，释放一些内存。通过设置最小服务器内存和最大服务器内存。

5、看缓存命中率、页写入/秒、页读出(SQL Sever |缓冲管理器)计数器的值。

Buffer catch hit ratio计数器的值应该稳定的保持较高的数值，同时Page Reads/sec、Page Writes/sec计数器的值应该很低。

如果Buffer catch hit ratio计数器的值较低，且Page Reads/sec、Page Writes/sec计数

器的值较高。可以得出缓存命中率较低，可以考虑增加Buffer pool，增加内存用于数据高速缓存。

6、查看Thread Count（sqlservr）:process计数器的值。

SQL SERVER默认的最大工作线程为255，若该计数器的值小于255，可以考虑将SQL SERVER的最大工作线程改为一个较小的值，有可能提高性能。

7、查看User Connections（SQL Server General Statistics）计数器的值。

由于每个用户连接都消耗一些内存，配置的用户连接数过高会影响吞吐量。将用户连接数设置为预期的最大并发用户数。

8、调整虚拟内存的大小。

因为虚拟内存使用时，是耗物理内存的。一般大小设置位物理内存的2.5~4倍。

9、增加纤程

并行可以提高执行效率，但是也可能引起CPU高利用率。

解决办法之一：利用增加纤程或者增加CPU。

可以更新，安装一些相应的补丁，增加并行的操作能力。

……

有关程序设计、代码编写：

1、查看Average Wait Time (ms)、Lock Requests/sec、Number of Deadlocks/sec（SQL Server |Locks）计数器的值。

若Lock Requests/sec数值较大，会引起上下文切换增加，

若Lock Requests/sec、Number of Deadlocks/sec的值较大，可以得出软件系统存在死锁及长时间锁等待情况，可以考虑修改有关锁的程序。

2、查看Context Switches/sec（System）、%processor time（processor）计数器的值。

Context Switches/sec计数器测量 Web 服务器计算机中的所有 CPU 切换线程上下文的速率。此计数器的高数值通常说明存在高的锁争用，或是线程在用户模式与内核模式之间有大量切换。可能需要使用采样分析器和其他工具进一步研究。

如果系统的吞吐量降低并且CPU 的使用率很高，并且此现象发生时切换水平在15000 以上，那么意味着上下文切换次数过高。

3、查看Batch Requests/sec、SQL Compilations/sec、SQL Re-Compilations/sec (SQL Sever |SQL Statistics)计数器的值。

Batch Requests/sec数值较低，且SQL Compilations/sec、SQL Re-Compilations/sec 保持较高数值，可以得出软件系统存在大量的编译及重编译现象。会占用较多的CPU利用率。

4、查看Pool Nonpaged Bytes（Memory）计数器的值。

Pool Nonpaged Bytes 指在非分页池中的字节数，非分页池是指系统内存(操作系统使用的物理内存)中可供对象(指那些在不处于使用时不可以写入磁盘上而且只要分派过就必须保留在物理内存中的对象)使用的一个区域。缓慢增长表示存在内存泄漏问题。

……