Windows Performance Analysis Field Guide笔记汇总

书中大量篇幅介绍了各种磁盘（虚拟）内存的概念和性能指标的查看。这对于我们实时监控Windows的运行时性能，预警性能不足的方案提供了数据参考。对于cpu和网络，开机性能相关的性能指标着墨较少。
对于Windows的卡顿延迟或卡死挂起现象的原因做了预测。
可惜他没有更深入地传授性能瓶颈的来源：如某些进程，某些驱动程序，乃至某个函数。

1 作者简介

Clint Huffman。于 1999 年加入 Microsoft，
支持 Web 技术和 Microsoft 负载测试工具，后来在 Microsoft 服务实
验室担任测试顾问，帮助人们进行负载测试。在那里，他找到了解决
Windows 性能问题的热情。 2006 年，他加入 Microsoft Premier
Field Engineering (PFE)，负责处理 Microsoft BizTalk Server 性能问
题，结果发现大多数问题都可以通过分析操作系统资源来诊断。有人可能
会说，Windows 的性能分析与其说是科学，不如说是一门艺术。好吧，克
林特努力使它尽可能成为一门科学，并将其带给大众。 Clint 最出名的可
能是日志性能分析 (PAL) 工具，它简化了性能监控日志的分析。

2 书中介绍的工具

Windows自带的:Perfmon.msc, Resmon，wmi,Poolmon
Windows Performance Toolkit的Windows Performance Analyzer, Windows Performance Record
SysInternals的VMMap，Process Explorer,Autoruns
Resource Monitor
Performance Analysis Logs

3 存储与网络相关

3.1 存储

如果我只有一个磁盘性能问题指标，那就是“\Logical Disk()\Avg.Disk sec/Transfer” 性能计数器。此计数器是磁盘传输（根据操作系统的读取或写入操作）的平均时间，以秒为单位。换句话说，它是所有磁盘传输等待磁盘驱动程序服务的平均时间。
如果我只有两个磁盘性能问题指标，我会使用“\LogicalDisk()\Avg.Disk sec/Read”和“ \LogicalDisk(*)\Avg.Disk sec/Write”。这些计数器与 sec/Transfer 计数器的工作方式相同，但只是中断的读取和写入。了解读取或写入是否存在问题有助于识别磁盘缓存问题。

回到餐厅的类⽐，这些计数器就像询问每个离开餐厅的人在点餐后需要多长时间才能拿到他们的食物，然后定期计算该时间范围内的平均值。如果平均值计算过于频繁，则可能需要管理的数据过多，但如果采样频率太低，则难以确定午餐高峰时间或晚餐高峰时间。
如果任何延迟计数器平均大于存储设备的平均服务时间，则需要进行更多调查。大多数 5400 RPM 磁盘驱动器的预期服务时间约为 17 ms，而 7200 RPM 磁盘驱动器的预期服务
时间约为 13 ms，因此通常接受的阈值旧（当您不知道正在使用的存储设备的服务时间时） ) 为 15 毫秒。这意味着如果磁盘驱动器在队列中总是有一个未完成的 I/O请求，那么每个 I/O 将在平均预期服务时间或更短的时间内得到服务（许多因素可以显着提高 I/O 请求的完成率）。当您引入许多未完成的I/O 请求时，它们都在等待，就像客户在等待他们的食物一样，它们各自的延迟计时器都增加了。
普通存储设备的预期IOPS和服务时间：

存储设备	IOPS	服务时间（ms）
3.5寸软盘
5400rpm硬盘	60	17
7200rpm硬盘	80	14
10K rpm硬盘	125	11
15K rmp硬盘	200	6
固态硬盘	5000	0.2

在任何情况下，当磁盘空间不足时，释放空间以防止应用程序或服务故障非常重要。
我们（Microsoft 支持）经常被问到是否应该使用 PhysicalDisk计数器或性能监视器中的 LogicalDisk 计数器用于磁盘分析。问题不应该是哪个计数器更好，而是理解他们测量什么。我通常从 LogicalDisk 计数器开始，因为它是最接近创建 I/O 需求的应用程序的度量。我的意思是当微软SQL Server写入磁盘，它写入逻辑磁盘，所以从应用程序的角度来看，逻辑磁盘的性能⽐底层物理磁盘性能更重要。如果我看到两个或更多逻辑磁盘性能不佳，我调出PhysicalDisk 计数器，看看它们是否与同一个物理磁盘相关。
性能监视器很少能够解决磁盘性能问题，但它可以指示何时需要进行更多调查或磁盘何时可能成为瓶颈。
如果“\LogicalDisk(?)\Avg.Disk Queue Length”大于2（说明磁盘队列有工作要做）
并且“\LogicalDisk(?)\Avg.Disk sec/Transfer”（指示出IO在队列中等待直到完成的平均时间，也就是通常认为的反应时间）大于平均期望服务时间
并且“\LogicalDisk(?)\Bytes/Read|Write”小于64KB（磁盘硬件的平均期望服务时间是以64KB或更小的负载来测量的）
那么磁盘就是过载的。
如果“\LogicalDisk(?)\Bytes/Read|Write”大于64KB，并且平均期望服务时间大于阈值10ms，那么？逻辑盘要被分析。
为了使这种分析更加容易，日志性能分析 (PAL) 工具可以使用我们刚刚讨论的复杂公式分析计数器日志，并在磁盘出现性能问题时进行诊断。
但我喜欢将这些工具视为性能分析的“显微镜”，而将 Perfmon视为高级视图。你当然不会带着显微镜四处走动。话虽如此，我们在数据收集方面付出了很多努力，以确保在收集大量数据的同时，它对系统尽可能没有影响，并且在生产中使用是安全的。我的建议是使用性能监视器来了解您正在处理的资源，然后使用 WPR/WPA 来挖掘并找到根本原因。
如果需要证据来证明存储硬件是否性能不佳，请考虑使用本章后面讨论的 Storport 跟踪。当需要在 Storport 驱动下进行性能分析时，需要硬件供应商提供的工具。这是因为 Storport 驱动程序是将 I/O 请求交给硬件的最后一位软件。很少需要这种级别的跟踪，但如果存储管理员无法隔离驱动程序和SAN 硬件之间的问题，则可以使用此级别的跟踪。
如果需要有关文件系统过滤器驱动程序的性能影响的证据，请考虑使用 WPA 或 Sysinternals的Process Monitor。

3.2 网络

带宽是网络适配器每秒可以发送或接收的潜在数据量，通常是判断网络性能时的唯一考虑因素，但其他因素如延迟、丢包、冲突、重传和硬件都应该考虑。
幸运的是，Windows 7、Windows Server 2008 R2 和更高版本附带了一个资源监视器版本，可提供网络延迟、数据包丢失和其他每个 TCP/IP 会话的详细信息 比以往任何时候都详细得多。真的确实很酷的东西！不幸的是，这些数据不能以性能计数器的形式提供。此外，Windows 性能分析器(WPA) 工具没有与网络相关的 ETW 数据的解析器。总之，没有性能计数器可以用作网络性能的初始指标Windows Vista、Windows Server 2008 和更高版本上的问题，则使用网络性能相关工具。
pathping工具跟踪路由（沿途的所有网络节点）并发送 100 个突发沿途对每个节点执行 ping 请求。它计算丢包和平均值每个节点的延迟。这在尝试确定是否存在不良情况时非常有用期望值。沿路径的节点。此外，这有助于确定哪里有慢（高延迟）连接，可能对网络应用程序（例如国际 Web 应用程序）产生重大影响。
确保网络适配器以预期的带宽（连接速度）运行非常重要。否则，性能可能会下降。性能计数器\Network Interface(*)\Connection Bandwidth 是当前网络适配器与有线网络交换机协商的连接速度或无线接入点。
网络利用率百分比（使用率与最大值的比率）很有帮助。在确定网络适配器是否不堪重负，但请记住，这是只能在 NIC 和网络设备（交换机、路由器、WAP）之间测量
根据我的经验，最常见的网络瓶颈是chattiness（网络往返次数）和延迟（数据包往返所花费的时间），而不是利用率
我最讨厌的一个问题是一个 Web 应用程序，它频繁且不必要地往返于 Web 服务器。往返行程对于请求到达服务器和 Web 应用程序（客户端）接收它有延迟（延迟）。即使没有数据正在传输，仅发出请求的行为也会显着减慢等待它的应用程序的速度。这就是为什么在慢速网络上测试网络应用程序很重要的原因。
我曾经处理过一个 Web 应用程序，每次单击表单都会导致到 Web服务器的往返。它使应用程序使用起来非常乏味且耗时。在许多情况下，使用 Internet Explorer 的 F12 开发人员工具进行的简单 HTTP 跟踪可以显示此行为并帮助开发人员了解在何处进行优化
我的观点是要了解任何网络应用程序正在进行的往返次数，并尽可能合理地减少它们。您的低带宽、高延迟用户会感谢您。
网络分析进行更深入的调查，请考虑使用网络工具，例如 Microsoft Network Monitor。

4 内存相关

4.1 进程内存

本章的目的是介绍进程虚拟地址空间的概念以及如何识别和排除进程内存泄漏
VMMap（一个免费的 Sysinternals 工具）可以说是调查应用程序的虚拟内存使用情况的最好和最简单的工具。当我将 VMMap 附加到 Notepad.exe 的 x86（32 位）实例并将空闲内存和总（所有非空闲）内存相加时，我最终得到 2,097,440 KB，大约为 2 GB。这是此记事本实例可以寻址的最大虚拟地址空间量，与物理内存量和页面文件大小无关
需要以下性能计数器来识别应用程序何时可能超出虚拟地址空间： \Process()\Virtual Bytes， \Process()\ID Process。计数器\Process()\Virtual Bytes 测量每个进程的所有保留和提交的内存使用情况。保留内存和提交内存都占用应用程序的虚拟地址空间内的空间。
什么时候被认为是泄漏：内存泄漏是进程大小增加并随着时间的推移保留不必要的内存的情况。当一个进程最初启动并开始工作时，它需要内存才能运行，因此繁忙的进程使用大量内存是正常的。但是，当进程返回空闲状态时，它应该释放不需要的内存。进程的空闲状态（如果存在）可能不容易识别，因此长期监控进程很重要。
性能计数器日志显示了 7 天内系统上所有进程的组合私有提交内存(\Process (_Total)\Private Bytes)（黑粗线），它是慢慢泄漏系统提交的内存。系统提交费用 (\Memory\Committed Bytes) 是红线。每个谷值代表每个工作日的结束。理想情况下，内存使用量应该恢复到相同的量，但我们看到与前一天结束相比逐渐增加。由于客户隐私，此应用程序的进程名称受到审查。


为了帮助确定内存的哪个区域随着时间的推移而增加，请使用VMMap 附加到泄漏进程（一次只能附加到一个进程）。相关应用程序完成“预热”后，通过单击查看、刷新或按 F5 键刷新 VMMap。刷新后，时间轴按钮将启用。 Timeline 视图显示每次刷新时内存资源的相对差异。有足够的时间，应该会出现内存使用量增加的模式。
一旦收集了转储（.dmp 文件）（通常需要三个连续的转储），进行调试的人员通常会比较每个
转储中的内存结构以形成相关模式。DebugDiag 等免费工具可以自动进行这种比较，并生成一份报告，显示正在增长的堆以及可能与之相关的相关模块。

4.2 内核内存

本章讨论如何检测和调查内核虚拟地址空间的问题，以及它与系统提交的内存和物理内存的关系
需要监视三个主要的内核内存资源是否存在潜在问题。它们是分页池、非分页池和系统页表条目 (PTE)
64 位 (x64) 版本的 Windows 和 Windows Server 不太可能用完内核虚拟地址空间，因为 8 TB或 128 TB 的空间取决于 Windows 或 Windows Server 的版本，并且更有可能用完首先是物理内存或系统提交的内存。
如果 \Memory\System Page Table Entries 小于20,000，则系统内核虚拟地址空间不足。
如果使用量超过其各自最大大小的 75%，那么这是一个值得进一步调查的指标：

操作系统	池类型	32位之最大值	64位之最大值
Windows7和Win Server 2008R2	非分页	75%的内存或2GB中的较小的	75%的内存或128GB中较小的
Windows7和Win Server 2008R2	分页	2GB或系统提交限制中的较小的	128GB或系统提交限制中较小的
WIndows8和Win Server2012	非分页	75%的内存或2GB中的较小的	2被内存或128GB中较小的
WIndows8和Win Server2012	分页	2GB或系统提交限制中较小的	348GB或系统提交限制中较小的
Windows8.1和Win Server2012R2	非分页	75%内存或2GB中较小的	2倍内存或16TB中较小的
Windows8.1和Win Server2012R2	分页	2GB或系统提交限制中较小的	15.5TB或系统提交限制中较小的

我知道监控系统PTE缺失的唯一方法是使用 \Memory\ System Page Table Entries 性能计数器，而不是调试内核。寻找小于 20,000 的值。当低于 20,000 时，系统可能开始无法适应内存分配。当低于 15,000 时，内存分配可能会更频繁地失败。这方面的一个例子是记事本根本无法启动。每个应用程序和每个驱动程序在这种情况下的行为都不同，甚⾄可能报告不相关的错误。
尽管 WPR 收集了大量数据，但实际上它的开销很小。它旨在在生产环境中运行。默认情况下，它在循环内存缓冲区中收集数据，因此它可以无限期地运行。只需单击“保存”按钮并按照提示在一分钟或更长时间后停止收集数据。
Poolmon和windbg的“!vm”展示虚拟内存的使用明细

4.3 系统提交内存

本章涵盖了您需要了解的有关系统提交的内存、如何监视此资源以及如何对其进行故障排除的知识。
如果您曾经看到一条弹出消息说系统“虚拟”内存不足，那么这意味着系统无法使用物理内
存和页面文件来支持任何进一步的内存需求。当系统处于这种状态时，提交的内存分配更有可能失败，从而导致应用程序无法启动，并且已经运行的服务、应用程序和驱动程序可能会开始出现故障。因此，跟踪系统提交的内存使用情况非常重要
系统提交限制是物理内存和系统上组合的所有页面文件大小的总和

当 system commit charge大约超过系统提交限制的 90% 时，页面文件将增加以适应它。这将继续发生，直到页面文件达到物理内存大小的三倍或 4 GB，以较大者为准。这一切都假设磁盘上的系统分区足够大以容纳该大小的页面文件。
下图系统提交限制15.8GB，system commit charge 9.2GB

性能监视器有三个与系统提交内存相关的计数器，\Memory\Commit Limit、\Memory\Committed Bytes 和\Memory% Committed Bytes In Use
保证对系统已提交内存进行更多调查的初始指标是为计数器 \Memory% Committed BytesIn Use 计数器寻找大于 75 的值。大于75则列为警告，小于90则列为严重。
所有系统提交的内存都到哪里去了？以下是可能消耗系统已提交内存的常见嫌疑人的列表。
1.处理私有内存，包括Address Windowing Extensions （AWE）内存使用
2. 内核池内存
3. 驱动程序锁定内存
4. System committed backed shared memory
windbg的“!vm”显示
Process Private Memory:系统提交内存最常见的消费者是进程。进程需要已提交的内存才能运行，繁忙的应用程序进程消耗很大一部分系统已提交的内存是正常的。尽管如此，重要的是要跟踪哪些进程消耗最多。进程私有内存可以通过许多工具进行跟踪，例如任务管理器、资源监视器和 Sysinternals的Process Explorer。性能计数器是\Process(*)\Private Bytes，最接近的 WMI 属性是Win32_Process.PageFileUsage。
驱动程序锁定内存：例如虚拟化驱动程序、防病毒或反恶意软件驱动程序、显卡和磁盘驱动程序。驱动程序锁定内存的常见消费者是虚拟化软件
SYSTEM COMMITTED BACKED SHARED MEMORY SECTIONS：一个进程可以创建一个共享内存部分来与另一个进程共享内存，这种内存分配将立即增加系统提交费用。在内核调试器中使用命令“!vm 1”检测共享的已提交内存——Shared Commit
SYSTEM CACHE RESIDENT MEMORY:系统缓存消耗物理内存，但不计入system commit charge
内核池内存：查看 Pool Paged的使用情况并不能直接指示系统提交的内存使用情况，因为上面提到的计数器和值正在测量保留和提交的内存使用情况。对于 Pool Paged 正在使用的系统提交内存的真实数量，请使用带有“！vm”命令的内核调试器并查看 PagedPoolCommitted 字段。

4.4 页面文件

页面文件（也称为分页文件）是磁盘上可选的隐藏系统文件，可用于支持系统故障转储和扩展系统提交的内存量（也称为“虚拟内存”），系统可以回收之。它还允许系统从物理内存中删除不经常访问的修改页面，以允许系统更好地将物理内存用于更频繁访问的页面
页面文件被频繁使用：承载页面文件的逻辑磁盘被频繁使用并且磁盘不堪重负。磁盘过载意味着磁盘在磁盘队列中不断有 IO 请求数据包，并且响应时间大于 IO 大小的预期。请记住，跟踪页面文件读取和写入只能通过文件 IO 跟踪来完成。在这种情况下，系统会定期在托管页面文件的磁盘上等待。由于磁盘的响应速度明显慢于物理内存，因此系统经常会感觉迟缓或无响应
其他与页面文件相关的性能计数器：
\MEMORY\PAGES/SEC 和其他HARD PAGE FAULT计数器。性能计数器 \Memory\Page/sec、\Memory\Page Reads/sec 和 \Memory\Page Inputs/sec 测量硬页错误（必须由磁盘解决的错误），“可能”或“可能不会”是与页面文件或物理内存不足有关。硬页错误是操作系统的正常功能，在读取需要的部分文件（如 DLL和 EXE）、读取内存映射文件或从页面文件读取时发生。这些计数器的高值（过度分页）表示磁盘访问（在 x86 和 x64 版本的 Windows 和 Windows Server 上每个页面错误 4KB），这可能会增加系统范围延迟的可能性，假设相关磁盘已不堪重负。因此，建议监控与这些计数器相关的托管页面文件的逻辑磁盘的磁盘性能

4.5 物理内存

如果我必须选择一个单一的、简单的低物理内存条件指标，那么它将监控性能计数器
\Memory\Available MBytes。这是因为当可用内存较低时（少于安装的物理内存的 10%），系统通常会产生比正常情况更多的磁盘 IO
假设系统只有不到 10% 的可用物理内存并且系统有一个或多个可用的页面文件，那么需要检查托管页面文件的磁盘是否不堪重负以及它们是否能够处理增加的分页
一些迹象表明可用内存不足 (\Memory\Available MBytes)、硬页面错误增加
(\Memory\Pages/sec)、进程工作集 (\Process(_Total)\Working Set) 减小（这很可能是一种通常称为“全局工作集调整”的情况）以及页面文
件使用量增加(\Page File()%Usage)。当托管页面文件的磁盘无法跟上增加的负载时，就会出现“系统范围的延迟”。
识别承载可用页面文件的逻辑磁盘:首先，确定哪些逻辑磁盘正在托管页面文件并且未满。这可以通过查看 \Paging File()% Usage的实例并查找小于 100 的值来完成。
磁盘是否不堪重负:Avg. Disk Queue Length是一个不错的选择，因为它可以计算平均可能的队列长度。我们检查队列长度不是因为主轴的数量，而是因为这意味着磁盘不断有工作要做。请记住，队列长度本身并不能确定磁盘是否不堪重负，但它确实告诉我们磁盘是否有持续的工作要做。如果没有 IO 请求排队，那么磁盘没有工作要做（不忙）并且磁盘的性能可以认为是好的，直到它再次有工作要做。最后，检查未完成请求的平均 IO 大小和响应时间。
综上所述，页面文件使用量显着增加的大型工作集修剪仅表明该活动正在发生。如果托管页面文件的磁盘被活动淹没，这只是一个真正的问题。因此，具有系统范围延迟的低物理内存条件实际上就是避免磁盘 IO 和压倒这些磁盘
事实是没有足够的性能计数器来真正说明所有物理内存使用情况。这主要是由于物理内存的实际使用和引用方式“不那么明显”。话虽如此，一些性能计数器可以提供一些线索，例如\Memory\Available MBytes、\Memory\Pool Nonpaged Bytes、\Memory\System Cache Resident Bytes和\Process(*)\Working Set，它们直接测量物理内存使用
驱动程序锁定的内存与使用非分页池内存的驱动程序不同。这意味着驱动程序锁定的内存不会出现在非分页池中

5 处理器相关

系统的性能通常与处理器的数量及其时钟速度有关，但通常情况下，磁盘等其他资源往往是最不堪重负的资源。当处理器不堪重负时，通常是由于一个或多个线程正在执行代码。这意味着任何使其更高效的更改都需要更改代码。查看调用堆栈可能很困难，并且通常会导致比本书更深入的调试
如果处理器在 \Processor()% DPC Time 或 \Processor()% Interrupt Time 上花费超过 10% 的时间，则可能存在大量使用或驱动程序或部件出现问题的硬件。中断和 DPC（延迟过程调用）与硬件和驱动程序资源使用有关。如果系统的处理器始终花费超过 10%的时间来服务中断（\Processor()% Interrupt Time）或 DPC（\Processor()% DPC Time），那么值得收集 ETW追踪调查。

6 开机性能

boot性能不佳的常见原因：
Services that don’t flag when started
Synchronous group policies
Improper BIOS settings
Boot scanners
Superfetch disabled
磁盘加密软件
网络延迟
不必要的登录脚本
启动项过多
WPA 中的引导阶段
Pre Session Init：BIOS 固件进行开机自检并执行预引导说明。在此期间，系统正在寻找可启动媒体。对可启动媒体的过多检查可能会导致此阶段出现不必要的延迟。
Session Init：加载内核和预引导相关的服务。长时间的延迟可能是视频 BIOS 或驱动程序相关 可能需要更新 BIOS。
Winlogon Init：启动更多服务，验证机器帐户，登录用户
Explorer Init：用户已通过身份验证，但用户的桌面正在创建的。在此阶段结束时，会出现桌面。
Post Boot：桌面已经出现，但由于应用程序和服务启动时磁盘过载等原因，系统可能尚未处于可用状态

7 日志性能分析(PAL)工具

PAL 工具使用本书中提到的所有性能计数器阈值，分析计数器日志，并生成显示警告和严重警报的HTML 报告。将其视为性能分析的“简单”按钮。话虽如此，该工具旨在成为一种节省时间的工具，而不是替代性能分析。
感觉像是pal收集了作者对系统或某些应用软件的性能条目阈值。我们再把这些条目载入perfmon.msc，收集得到的结果再传回pal，再跟阈值做比较。

8 可能导致整机卡死的原因

在系统运行一段时间后系统完全挂起期间，如果键盘灯工作正常，则很可能是软件状况导致
系统挂起或看似挂起。非常繁忙或编写不佳的驱动程序是这种情况的常见原因。在系统运行一段时间后系统完全挂起期间，如果键盘灯工作正常，则很可能是软件状况导致。系统挂起或看似挂起。非常繁忙或编写不佳的驱动程序是这种情况的常见原因。
潜在原因1：处理器或磁盘使用率高。 如果系统每隔几秒就响应一次，则更有可能是处理器或磁盘等资源使用率高的情况。
潜在原因2：内核池内存不足如果在系统挂起期间没有证据表明处理器或磁盘使用率很高（在第 3 章和第10章中有详细说明） ，那么系统可能会以一种或多种方式出现内存不足。无限期持续的完整系统挂起（意味着几分钟内没有更新用户界面）可能表明缺少内核非分页池内存。
潜在原因3：高处理器中断或 DPC此症状通常与高内核模式处理器使用率或频繁的处理器中断有关。
当内核资源耗尽内存时，它将无法在该资源中分配内存。这会很快导致系统范围的挂起和/或应用程序无法运行。这就是为什么知道如何检测内核何时资源不足很重要的原因。
当没有足够的可用系统 PTE 时，系统无法将虚拟地址空间页面映射到物理内存页面。这可能导致应用程序或系统挂起
系统提交限制是一种人为的资源，它是物理内存和系统上所有页面文件的总和。它可
以防止系统过度使用或“过度承诺”物理内存和页面文件。因此，当系统用完系统提交的内存时，它不能支持任何更多提交的内存请求，直到系统提交限制增加或直到一些已提交的内存被释放回系统。用完可能会导致应用程序和/或系统挂起。因此，保持系统提交限制高于系统提交费用很重要。
物理内存不足的系统可能会出现以下症状：“滞后”或未能正确“绘制”用户界面;鼠标点击和键盘敲击迟缓或无响应;应用程序和服务无响应或速度非常慢;“使用中”内存高且可用物理内存非常低