ASP.NET性能监视参数详解

性能监视器- Performance Monitor

性能监视器是Windows自带的系统资源和性能监视工具. 性能监视器能够量化地提供CPU使用率, 内存分配状况, 异常派发情况, 线程调度频率等信息. ASP.NET能够提供每秒钟的请求数目, 请求响应时间等等. 性能监视器能够监视一段时间内上述资源的利用情况, 提供平均值和峰值。 

性能监视器有助于获取关于性能的具体指标, 监视问题出现时系统资源的变化情况. 通过检查性能监视器中一些重要计数器的变化情况, 往往能够找到一些比较有用的线索. 比如比较ASP.NET每秒请求数目, 请求响应时间和CPU利用率是否有相同的变化曲线就能看出性能是否跟负载相关。

解决性能问题的时候, 往往会让客户添加下面一些计数器进行性能收集。

• Process object下的所有计数器
• Processor object下的所有计数器
• System object下的所有计数器
• Memory object下的所有计数器
• 如果客户的程序时.NET程序, 还会添加以.NET开头的object下的所有计数器.
• 如果客户使用ASP.NET, 还会添加以ASP.NET开头的object下的所有计数器.

分析性能日志的时候, 重点观察下面这些计数器.

Process object

=============

Process object中的计数器可以根据目标进程分析内存, CPU, 线程数目和handle数目. 选出问题的目标进程, 然后分析目标进程的下面一些计数器.

   

%Processor Time

-------------------

该计数器是该进程占用CPU资源的指标. 即便进程繁忙的时候, CPU平均占用率应该在80%以内. 如果超过该数值, 可以认为程序发生了高CPU的问题. 另外一种问题是CPU波动幅度大. 虽然平均占用率不高, 但是上下跳动频繁. 在某一个短时间段里面, 会有连续高CPU的情况出现.

   

Handle Count

------------------

该计数器记录了当前进程使用的kernel object handle数量. Kernel object是重要的系统资源. 当程序进入稳定运行状态的时候, Handle Count数量也应该维持在一个稳定的区间. 如果发现Handle Count在整个程序周期内总体趋势连续向上, 应该考虑程序是否有Handle Leak.

   

ID Process

------------------

该计数器记录了目标进程的进程ID. 你可能觉得奇怪, ID有什么好观察的? 进程ID是用来观察程序是否有重启发生. 比如ASP.NET工作进程可能会自动回收. 由于进程名都相同, 所以只有通过进程ID来判断是否有重新启动现象. 如果ID有变化, 那么而看看程序是否发生崩溃或者Recycle.

   

Private Bytes

------------------

该计数器记录了当前通过VirtualAlloc API进行的, Commit了的Memory数量. 无论是直接调用API申请的内存, Heap Manager申请的内存, 还是CLR的managed heap, 都算在里面. 跟Handle Count一样, 如果在整个程序周期内总体趋势连续向上, 说明有Memory Leak.

   

Virtual Bytes

------------------

该计数器记录了当前进程申请成功的用户态总内存地址, 包括DLL/EXE占用的地址和通过VirtualAlloc API进行的, Reserve了的内存地址数量, 所以该计数器应该总大于Private Bytes. 一般说来, Virtual Bytes与Private Bytes的变化大致一致. 由于内存分片的存在, Virtual Bytes与Private Bytes一般保持一个相对稳定的比例关系. 当Virtual Bytes与Private Bytes的比例大于2的时候, 程序往往有比较严重的内存地址分片.

   

Processor object

==============

Processor object记录系统中芯片的负载情况. 由于普通程序并不可以绑定到某个具体的CPU上执行, 所以在多CPU机器上观察Total Instance也就足够了.

   

%Processor Time

----------------------

该计数器跟Process下的%Processor Time的意义一样, 不过这里记录的不是针对具体的某一个进程, 而是整个系统. 通过把该计数器跟Process下的同名计数器一起比较, 就能看出系统的高CPU问题是否是由于单一的某个进程导致的.

   

System object

==============

System object记录系统中一个整体的统计信息. 所以不区分instance. 通过比较System object下的counter和其他counter的变化趋势, 往往能看出一些线索.

   

Context Switch/ sec

--------------------

Context Switch标示了系统中整体线程的调度, 切换频率. 线程切换是开销比较大的操作. 频繁的线程切换回导致大量CPU周期被浪费. 所以当看到高CPU的时候, 一定要与Context Switch一起比较. 如果两者有相同的变化趋势, 高CPU往往是由于contention(线路争夺)导致的, 而不是死循环.

   

Exception Dispatches/ sec

-------------------

Exception Dispatches表示了系统中异常派发, 处理的频繁程度. 跟线程切换一样, 异常处理也需要大量的CPU开销. 分析方法跟Context Swith雷同.

   

File Data Operations/ sec

-------------------

File Data Operations记录了当前系统中磁盘文件读写的频繁程度. 通过观察该计数器跟其他性能指针的变化趋势, 能够判断磁盘文件操作是否是性能瓶颈. 类似的计数器还有Network Interface, Bytes Total/ sec

   

Memory Object

=============

Memory object记录了当前系统中整体内存的统计信息.

   

Avaiable Mbytes 和 Committed Bytes

---------------------

Available Mbytes记录了当前剩余的物理内存数量. Committed Bytes记录了所有进程commit的内存数量. 结合两个计数器可以观察到:

1. 两者相加可以粗略估计系统总体可用内存的多少, 便于估计物理配置.
2. 当Available Mbytes少于100MB的时候, 说明系统总体内存紧张, 会影响到系统所有进程的性能. 应该考虑增加物理内存或检查内存泄露.
3. 通过比较Process object中的Private Bytes和Virtual Bytes, 便于进一步确认是否有内存泄露, 判断内存泄露是否是由某一单个进程导致的.

Free System Page Table Entries, Pool Paged Bytes 和 Pool Nonpaged Bytes

--------------------

这三个计数器可以衡量核心态空闲内存的数量. 特别是当使用/3GB开关后, 核心态内存地址被压缩, 容易导致核心态内存不足, 继而引发一些非常奇怪的问题.

   

.NET CLR Memory object

=============

.NET CLR Memory object记录了CLR进程中跟CLR相关的内存信息. 该类别下的所有计数器都很有趣, 意思也非常直接. 建议用一个例子程序进行测试和研究. 下面是两个最常用的计数器.

   

Bytes in all heaps

----------------------

Bytes in all heaps 记录了上次GC发生时所统计到的, 进程中不能被回收的所有CLR object占用的内存空间. 该计数器不是实时的, 每次GC发生的时候, 该计数器才更新. 与同一进程的Process下的Private Bytes比较, 可以区分出managed heap和native memory的变化情况. 对于memory leak, 便于区分是managed heap的leak, 还是native memory 的leak.

   

%Time in GC

%Time in GC记录了GC发生的频繁程度. 一般来说15%以内算比较正常. 当超过20%时, 说明GC发生过于频繁. 由于GC不仅带来很高的CPU开销, 而且还需要挂起目标进程的CLR线程, 所以高频率GC是非常危险的. 通过跟CPU利用率和其他性能指标的比较, 往往能够看出GC对性能的影响. 高频率的GC往往因为:

1. 负载过高.
2. 不合理的架构, 对内存使用率不高.
3. 内存泄露, 内存碎片导致内存压力.

性能监视参数详解

ASP.NET 支持两组性能计数器：系统和应用程序。前者在 ASP.NET 性能计数器对象中的 PerfMon 中公开；后者在 ASP.NET Applications 性能对象中公开。ASP.NET 性能对象中的 State Server Sessions 计数器（仅适用于在其中运行状态服务器的服务器计算机）和 ASP.NET Applications 性能对象中的 Sessions 计数器（仅适用于进程中发生的用户会话）之间存在很大的差异。

在监视 ASP.NET Web 应用程序的性能时，应该始终跟踪下表中列出的性能计数器。

   

性能对象	性能计数器
ASP.NET	Application Restarts
ASP.NET	Requests Queued
ASP.NET	Worker Process Restarts
ASP.NET Applications	Errors Total
ASP.NET Applications	Requests/Sec
Processor	% CPU Utilization

ASP.NET 系统性能计数器

ASP.NET 支持以下 ASP.NET 系统性能计数器。它们汇集 Web 服务器计算机上所有 ASP.NET 应用程序的信息，或者它们通常应用于运行相同应用程序的 ASP.NET 服务器的系统。它们可能包含 Web 场和 Web 园。

性能对象	计数器	实例	描述
Processor（处理器）	% Processor Time（处理器时间百分比）	__Total	"% Processor Time"监视运行 Web 服务器的计算机的 CPU 利用率。低 CPU 利用率或者无法最大化 CPU 利用率（无论客户端负载为多少）都表明 Web 应用程序中存在对资源的争用或锁定。
Process（进程）	% Processor Time（处理器时间百分比）	aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）	由 ASP.NET 工作进程所使用的处理器时间所占的百分比。在将标准负载情况下的性能与先前捕获的基准进行对比时，如果此计数器的值出现下降，则说明降低了对处理器的需求，因此也提高了伸缩性。
Process（进程）	Working Set（工作集）	aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）	由 ASP.NET 主动使用的内存数量。虽然应用程序开发人员对应用程序使用的内存数量拥有最大的控制权，但系统管理员也可通过调整会话的超时期限来显著影响这一点。
Process（进程）	Private Bytes（专有字节）	aspnet_wp 或 w3wp（具体情况视 IIS 版本而定）	Private Bytes 是当前分配给该进程且不能由其他进程共享的内存数量（以字节计）。不时出现的尖峰表明某些地方存在瓶颈，会导致工作进程继续持有不再需要的内存。如果此计数器突然下降为接近 0 的值，则可能表示 ASP.NET 应用程序由于无法预料的问题进行了重启。为了验证这一点，请监视"ASP.NET Application Restarts"计数器。
ASP.NET Applications（ASP.NET 应用程序）	Requests/ Sec（每秒的请求数）	__Total	允许您检验请求的处理速度是否于发送速度相适应。如果每秒请求数的数值低于每秒产生的请求数，则会出现排队现象。这通常意味着已经超过了最大请求速度。
ASP.NET Applications（ASP.NET 应用程序）	Errors Total（总错误数）	__Total	在执行 HTTP 请求期间发生的错误总数。包括任何分析器、编译或运行时错误。此计数器是"Errors During Compilation"（编译错误数）、"Errors During Preprocessing"（预处理错误数）和"Errors During Execution"（执行错误数）计数器的总和。运转正常的 Web 服务器不应产生任何错误。如果错误发生在 ASP.NET Web 应用程序中，它们的存在可能会让实际的吞吐量结果产生偏差。
ASP.NET	Request Execution Time（请求执行时间）		显示了呈现所请求页面并将其传送给用户所需的时间（以毫秒计）。跟踪此计数器通常要比跟踪页面呈现时间效果更好。此计数器可以更全面地衡量从开始到结束的整个请求时间。在与基准进行对比时，如果此计数器的平均值较低，则说明应用程序的伸缩性和性能均得到了改善。
ASP.NET	Application Restarts（应用程序重新启动）		应用程序在 Web 服务器生存期间发生重新启动的次数。每次发生 Application_OnEnd 事件时，应用程序的重新启动次数都会增加。应用程序进行重新启动的原因可能是：更改了 Web.config 文件、更改了存储在应用程序的 \bin 目录下的程序集、或者 Web Forms 页面中发生了太多的更改。如果此计数器的值出现意料之外的增加，说明某些不可预知的问题导致 Web 应用程序被关闭。在这种情况下，应该认真调查问题原因。
ASP.NET	Requests Queued（排队的请求数）		在队列中等待服务的请求数。如果此数字随着客户端负载的增加而呈现线性的增长，则说明 Web 服务器计算机已经达到了它能够处理的并发请求极限。此计数器的默认最大值为 5,000。您可以在计算机的 Machine.config 文件中更改此设置。
ASP.NET	Worker Process Restarts（工作进程重新启动）		工作进程在服务器计算机上重新启动的次数。如果出现意料之外的故障或者被有意回收，则工作进程会重新启动。如果此计数器的值出现意料之外的增加，应认真调查问题原因。

ASP.NET Application 性能计数器

ASP.NET 支持以下应用程序性能计数器，可以使用这些计数器来监视单个 ASP.NET 应用程序实例的性能。这些计数器均有一个唯一实例 __Total__，该实例合计 Web 服务器上所有应用程序的计数器（与本主题第一节中描述的全局计数器类似）。__Total__ 实例始终可用。当服务器上没有应用程序时，这些计数器将显示零。

计数器	描述
Active Sessions（活动会话数）	活动会话的数量。此计数器反映了尚未过期的所有浏览器会话总数。这并不是同时处理的请求数，而是存储在 ReportServerTempDB 数据库中的会话数量。
Cache Hits/Sec（每秒缓存命中次数）	每秒从目录中取得的报告请求的数量。如果此值增加，而"Memory Cache Hits"的值不增加，则说明报告数据没有被重新处理，但是页面被重新呈现。将此计数器与 Memory Cache Hits/Sec 计数器一同使用，可以确定用于缓存、磁盘或内存的资源是否充足。
Cache Misses/Sec（每秒缓存未命中数）	每秒未能从目录中（与内存中相对）返回报告的请求数量。将此计数器与 Memory Cache Misses/Sec 计数器一同使用，可以确定用于缓存、磁盘或内存的资源是否充足。
First Session Requests/Sec（每秒的首次会话请求数）	每秒中从 Report Server 缓存中启动的新的用户会话数量。
Memory Cache Hits/Sec（每秒内存缓存命中数）	每秒中从内存中的缓存里取得报告的次数。内存中缓存是 Reporting Services 缓存的一部分，用于在内存或临时文件中保存已呈现过的报告。这样可以为请求提供最佳的性能，因为无需执行任何处理工作。如果使用内存中缓存，报告服务器将不会通过查询 SQL Server 来获得缓存的内容。
Memory Cache Misses/Sec（每秒内存缓存未命中数）	每秒中未能从内存中的缓存里取得报告的次数。
Next Session Requests/Sec（每秒的下一次会话请求）	每秒在现有会话中请求打开报告的次数。
Report Requests（报告请求）	当前处于活动状态并且将由 Report Server 进行处理的报告数量。
Reports Executed/Sec（每秒执行的报告数）	每秒成功执行的报告的数量。此计数器提供了有关报告处理量的统计信息。综合使用此计数器和 Request/Sec，比较可从缓存中返回的报告请求的执行情况。
Requests/Sec（每秒的请求数）	每秒向 Report Server 发出的请求数。此计数器跟踪由 Report Server 处理的所有类型的请求。
Total Cache Hits（缓存命中总数）	自服务启动以来，从缓存中获得报告的请求总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。
Total Cache Misses（总的缓存未命中数）	自服务启动以来，不能从缓存中获得报告的总次数。此计数器在 ASP.NET 停止该 Web 服务后被重设。可使用此计数器确定磁盘空间和内存是否充足。
Total Memory Cache Hits（总的内存缓存命中数）	自服务启动以来，从内存中缓存里返回的已缓存报告的总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。内存中缓存是在 CPU 内存中存储报告的那部分缓存。如果使用内存中缓存，报告服务器将不会通过查询 SQL Server 来获得缓存的内容。
Total Memory Cache Misses（总的缓存未命中数）	自服务启动以来，针对内存中缓存的缓存未命中总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。
Total Processing Failures（处理故障总数）	自服务启动以来，发生的所有报告处理故障的总数。此计数器在 ASP.NET 停止该 Web 服务后被重设。处理故障可能来自报告处理器，也可能来自任何扩展。
Total Reports Executed（执行的报告总数）	自服务启动以来得到成功执行的报告的总数。
Total Requests（总请求数）	自服务启动以来，向 Report Server 发送的所有请求的总数。

 

转载于:https://www.cnblogs.com/xJob/p/4156500.html