博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
[转]Windows 性能监视器工具-perfmon
阅读量:5789 次
发布时间:2019-06-18

本文共 8068 字,大约阅读时间需要 26 分钟。

hot3.png

Windows 性能监视器工具

如果需要在一台计算机上监视多个 Report Server 实例,可以同时或单独监视这些实例。选择要包括的实例是计数器添加过程的一部分。有关使用 Windows 附带的性能工具的更多信息,请参见微软 Windows 产品文档。

若要访问性能工具

从“开始”菜单上选择“运行”。

在“打开”文本框中输入“perfmon”,然后单击“确定”。

在性能监视器工具中,在左侧窗格里选择 System Monitor 对象,然后右击“性能”图表。

选择“添加计数器”。

现在,可以开始选择这些对象和要监视的计数器了。

ASP.NET 应用程序性能计数器

有关 ASP.NET 应用程序性能计数器的大部分信息最近已被合并到一个题为“改善 .NET 应用程序的性能和伸缩性”的综合文档中。下表描述了一些可用于监视和优化 ASP.NET 应用程序(包括 Reporting Services)性能的重要计数器。

性能对象 计数器 实例 描述

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 应用程序具有的特定性能问题时,下表中的性能计数器也可对您有所帮助。

性能对象 计数器 实例 描述

ASP.NET Applications(ASP.NET 应用程序)

Pipeline Instance Count(管线实例计数)

__Total

指定 ASP.NET 应用程序的活动请求管线实例的数量。由于只有一个执行线程可以在管线实例内运行,所以此数值反映了为特定应用程序处理的并发请求的最大数量。大多数情况下,在存在负载的情况下此数值较低为佳,这表明处理器得到了很好的利用。

.NET CLR Exceptions(.NET CLR 异常)

# of Exceps Thrown(引发的异常数)

 

显示应用程序中引发的异常数。如果此数值出现意料之外的增加,说明可能存在性能问题。如果仅仅存在异常,则并不需要担心,因为异常对于某些代码路径来说是正常工作的一部分。例如,HttpResponse.Redirect 方法通过引发一个不可捕获的异常 ThreadAbortException 来完成工作。同样,对 ASP.NET 应用程序跟踪此计数器也更加有用。使用“Errors Total”计数器确定该异常是否将导致应用程序出现意料之外的错误。

System(系统)

Context Switches/ sec(每秒的上下文切换次数)

 

测量 Web 服务器计算机上所有处理器切换线程上下文的速度。如果此计数器的值很高,可能表示对锁的争用频繁发生,或者在线程的用户模式和内核模式之间切换频繁。使用采样优化程序和其他工具执行进一步调查可证实上述猜测。

Reporting Services 性能计数器

Reporting Services 包括一组它自己的性能计数器,用于收集有关报告处理和资源消耗方面的信息。可通过 Windows 性能监视器工具中出现的两个对象来监视实例和组件的状态和活动:MSRS 2005 Web Service 和 MSRS 2005 Windows Service 对象。

MSRS 2005 Web Service 性能对象包括一组用来跟踪 Report Server 处理过程的计数器,这些处理过程通常通过在线交互式报告浏览操作而引发。这些计数器在 ASP.NET 停止该 Web 服务后被重设。下表列出了可用于监视 Report Server 性能的计数器,并描述了它们的目的。

性能对象:RS Web Service

计数器 描述

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 发送的所有请求的总数。

RS Windows Service 性能对象包括一组用于跟踪报告处理过程的计数器,这些处理过程是通过预定操作而引发的。预定操作可能包括订阅和交付、报告执行快照以及报告历史。微软的工作负载中并不包含任何预定操作或交付操作,此处列出这些性能计数器仅是便于您进行参考。

可使用此性能对象监视 Report Server Windows 服务。如果您准备在一个横向伸缩配置中运行 Report Server,那么这些计数器应用于所选的服务器,而不是应用于横向伸缩配置整体。这些计数器在应用程序域回收之时将被重设。下表列出了可用于监视预定和交付操作的计数器,并描述了它们的目的。

性能对象:RS Windows Service

计数器 描述

Cache Flushes/Sec(每秒缓存刷新次数)

每秒刷新缓存的次数。

Cache Hits/Sec(每秒缓存命中数)

每秒获取到缓存报告的请求数量。

Cache Misses/Sec(每秒缓存未命中数)

每秒未能从缓存中获得报告的请求的数量。

Delivers/Sec(每秒交付数)

每秒从各种交付扩展交付的报告的数量。

Events/Sec(每秒事件数)

每秒处理的事件数量。被监视的事件,包括 SnapshotUpdated 和 TimedSubscription。

Memory Cache Hits/Sec(每秒内存缓存命中数)

每秒中从内存中的缓存里取得报告的次数。

Memory Cache Misses/Sec(每秒内存缓存未命中数)

每秒中未能从内存中的缓存里取得报告的次数。

Report Requests(报告请求数)

当前处于活动状态并且将由 Report Server 进行处理的报告数量。可使用此计数器评估缓存策略。向特定呈现扩展提交的请求数。请求的数量可能比执行的报告数量多许多。

Reports Executed/Sec(每秒执行的报告数)

每秒成功执行的报告的数量。

Snapshot Updates/Sec(每秒快照更新数)

每秒报告执行快照的预定更新数量。

Total App Domain Recycles(应用程序域回收总数)

自服务启动以来回收的应用程序域总数。

Total Cache Flushes(缓存刷新总数)

自服务启动以来,Report Server 的缓存更新总数。

Total Cache Hits(缓存命中总数)

自服务启动以来,从缓存中获得报告的请求总数。

Total Cache Misses(总的缓存未命中数)

自服务启动以来,不能从缓存中获得报告的总次数。

可使用此计数器确定是否需要更多磁盘空间或内存。

Total Deliveries(总交付数)

由 Scheduling and Delivery Processor 交付的报告总数(对于所有交付扩展)。

Total Events(总事件数)

自服务启动以来发生的事件的总数。

Total Memory Cache Hits(总的内存缓存命中数)

自服务启动以来,从内存中缓存里返回的已缓存报告的总数。

Total Memory Cache Misses(总的缓存未命中数)

自服务启动以来,针对内存中缓存的缓存未命中总数。

Total Processing Failures(处理故障总数)

自服务启动以来,发生的所有报告处理故障的总数。处理故障可能来自报告处理器,也可能来自任何扩展。

Total Rejected Threads(被拒绝的线程总数)

拒绝执行异步处理后在同一线程中作为同步过程在以后进行处理的数据处理线程总数。

Total Report Executions(报告执行总数)

已执行报告的总数。

Total Requests(请求总数)

自服务启动以来得到成功执行的报告的总数。

Total Snapshot Updates(快照更新总数)

自服务启动以来,报告执行快照进行更新的总数。

如果您打算排除 Reporting Services 存在的性能问题,记录以下性能计数器通常很有帮助:ASP.NET、ASP.NET Applications、Process、System、Memory、Physical Disks、.NET Exceptions、.NET Memory、.NET Loading、.NET CLR Locks and Threads 以及 .NET CLR Data。

可选的 Reporting Services 性能计数器  

以下列出了一些适用于 RS Web Service 但在默认情况下并未安装的性能计数器。但是,在执行性能优化工作时,可以通过这些计数器来改善您洞察性能的能力。为实现这个目的,请在命令提示符中执行以下语句:

installutil.exe /u ReportingServicesLibrary.dll

然后再执行:

installutil.exe ReportingServicesLibrary.dll

为了成功执行该语句,您可能首先需要修改您的路径,在路径中包含 Microsoft .NET Framework 的安装目录。在路径修改完毕后,请从包含 ReportingServicesLibrary.dll 文件的目录下执行先前语句。默认情况下,该文件安装在 C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL.instance\Reporting Services\ReportServer\bin 目录下。这些计数器没有进行彻底的本地化。

Active Database Connections(活动数据库连接)

某个时间处于活动状态的数据库连接的数量。只统计指向 Report Server 目录的连接。

Active Datasource Connections(活动数据源连接)

某个时间处于活动状态的数据库连接的数量。只统计由当前运行的报告打开的数据源连接。

Active Threads(活动线程)

当前处于活动状态的线程数量。在 Web 服务中,它包含一些为请求提供服务的线程。在交付服务中,它包含工作线程以及维护和轮询线程。

Byte count(字节计数)

对于上一次请求,在呈现当前报告时向客户端返回的字节数量。这与对应的执行日志条目相类似。

Row Count(行计数)

对于上一次请求,由当前报告返回的行的数量。这与对应的执行日志条目相类似。

Time in Compression(压缩时间)

对于上一次请求,在快照和 PDF 报告压缩上花费的时间(以毫秒计)。

Time in data source access(数据源访问时间)

对于上一次请求,在获取报告的数据源信息上花费的时间(以毫秒计)。其中包括执行查询和取回结果所需的时间。这与对应的执行日志条目相类似。

Time in database(数据库时间)

对于上一次请求,在获取 Report Server 目录信息上花费的时间(以毫秒计)。

Time in processing(处理时间)

对于上一次请求,在报告处理上花费的时间(以毫秒计)。这与对应的执行日志条目相类似。

Time in rendering(呈现时间)

对于上一次请求,在呈现报告上花费的时间(以毫秒计)。这与对应的执行日志条目相类似。

转载于:https://my.oschina.net/aiguozhe/blog/59733

你可能感兴趣的文章
Webpack中的sourcemap以及如何在生产和开发环境中合理的设置sourcemap的类型
查看>>
做完小程序项目、老板给我加了6k薪资~
查看>>
java工程师linux命令,这篇文章就够了
查看>>
关于React生命周期的学习
查看>>
webpack雪碧图生成
查看>>
搭建智能合约开发环境Remix IDE及使用
查看>>
Spring Cloud构建微服务架构—服务消费基础
查看>>
RAC实践采坑指北
查看>>
runtime运行时 isa指针 SEL方法选择器 IMP函数指针 Method方法 runtime消息机制 runtime的使用...
查看>>
LeetCode36.有效的数独 JavaScript
查看>>
Scrapy基本用法
查看>>
PAT A1030 动态规划
查看>>
自制一个 elasticsearch-spring-boot-starter
查看>>
【人物志】美团前端通道主席洪磊:一位产品出身、爱焊电路板的工程师
查看>>
一份关于数据科学家应该具备的技能清单
查看>>
机器学习实战_一个完整的程序(一)
查看>>
Web框架的常用架构模式(JavaScript语言)
查看>>
如何用UPA优化性能?先读懂这份报告!
查看>>
这些Java面试题必须会-----鲁迅
查看>>
Linux 常用命令
查看>>