【Fundamentals of Windows Performance Analysis】翻译，第三章： 通过Windows Performance Recorder收集日志

第三章 通过Windows Performance Recorder收集日志

在上一章中，我们回顾了在Windows上执行性能测量的基本方法。从前面调研的结果得到的结论，我们决定使用ETW对性能问题进行根因分析。在本章中，我们将向您介绍一个工具，它使性能跟踪收集成为一项简单的任务，您甚至可以要求不精通技术的最终用户执行该任务。

使用WPR收集ETL日志

回到第1章的练习1.1中，我们已经向您展示了如何使用Windows Performance Recorder (WPR)收集基本的ETL性能日志。在本书中，我们将依靠WPR来满足我们所有的跟踪收集需求，所以让我们花一点时间更详细地了解这个工具。

在WPR发布之前，为了收集ETL跟踪，您必须对ETW有很好的了解。这涉及到要启用哪些事件提供程序（有时仅有GUID引用）、要记录到哪些会话、要分配多少缓冲区以及要使用何种日志记录模式。您必须知道日志合并以及内核会话和用户会话之间的区别。更糟糕的是，命令行是捕获性能跟踪的唯一手段，而且选项的数量被证明是很难筛选的（尝试运行xperf –help start了解我们的意思）。虽然这种低级控制有时仍然是必要的，但在99%的场景中，您现在可以幸福地不用感知ETW如何完成其繁重的工作，而是专注于重要的事情——根本原因和修复性能问题。

WPR有两种变体：命令行和GUI。这两种工具都提供了与同一底层引擎相似的前端，这基本上可以让您：

• 使用WPR配置文件启动和停止录制，包括内置和自定义

• 查看WPR录制会话的状态

GUI版本自然更容易使用，但确实需要用户交互。另一方面，命令行版本在脚本和自动化方面可以非常有效。让我们仔细看看这些工具中的每一个。

WPR界面工具

在练习1.1中，我们已经向您介绍了WPR中的基本跟踪收集体验。我们在那里使用的是WPR的GUI版本，其二进制文件被适当地命名为wprui.exe。当您安装Windows Performance Toolkit时，WPR将注册为系统上的应用程序，您可以通过在“开始”屏幕/菜单中搜索“wpr”、“rec”或“perf”轻松查找它。

对于基本的第一级分类，工作流（workflow）是您真正需要知道的关于捕获性能跟踪的全部信息——只需启动Windows Performance Recorder GUI，点击“开始”，保持其运行，直到问题重现，然后点击“保存”并填写观察到的性能问题的描述。就是这样!你完了!那不是很容易吗？

图3.1至图3.5更详细地说明了这个非常典型的用户工作流。让我们再次了解这些步骤，在每一个步骤上花更多的时间。启动WPR时，您首先看到其基本简略视图，如图3.1所示。

此时，WPR被配置为记录第一级分类。在下一节中，我们将向您展示此录制配置文件中的内容，以及哪些其他配置文件可用。正如第一级分类名称所提示的，此配置文件记录了足够的数据，以启用性能问题的初始分类。对于大多数只想报告他们所遇到的性能问题的可操作测量的人来说，此初始默认值是一个完美的设置。每当有人抱怨其系统和/或应用程序的性能时，您只需要求他们使用WPR的第一级分类配置文件记录日志，然后与您共享该日志。

注意：您可以要求用户安装Windows性能工具包，如我们在第1章中所示。或者，如果没有安装的条件（例如生产服务器），您可以将四个WPR二进制文件复制到可移动驱动器（例如USB）或通过网络共享，然后从那里运行工具。您需要复制的文件是:

wprui.exe
wpr.config.xml
windowsperformancerecordercontrol.dll
windowsperformancerecorderui.dll

工具启动后，用户需要单击“开始”按钮以启动录制。录制正在进行后，WPR会让您了解为该录制分配的内存的最新情况。典型大小为系统物理内存的5%，可能会变得相当大——例如，在我们具有32GB内存的系统上，WPR分配了1960MB缓冲区，如图3.2所示。

请注意作为状态行的一部分提到的“In Memory...”。这表明WPR正在将其捕获到的测量保存到内存缓冲区（或更正式的是内存ETW会话）中。正如我们稍后将看到的，您还可以使用WPR将测量结果直接捕获到文件中。这样做的优点是内存占用空间较小，缺点是在整个场景中会引入额外的磁盘I/O。

注意：在大多数常见的客户端系统内存配置中，使用5%的内存进行跟踪是很好的。在具有大量内存（例如数百GB）的服务器上，您可能希望将该值降低到较小的数字，因为（对于内存跟踪）生成的日志可以与分配的缓冲区的大小一样大。问题是，您需要一台具有足够内存的分析机器来将日志完全加载到内存中，因为在撰写本书时，WPA不支持“滑动窗口”跟踪分析。我们实际上已经碰到过这种情况，即高端服务器的WPR使用了默认设置，生成了过大的ETL文件，导致无法将日志在典型客户端系统中分析。

注意：正如我们将看到的，一些配置文件，包括内置配置文件，可以配置为使用5%以上。事实上，实际上已经使用了15-20%。在这一点上，您真的必须问问自己，您是否正在影响您试图测量的场景，并确保您的日志捕获不会对系统造成内存压力。请注意，不同的场景具有不同的内存要求，因此影响一个场景的因素可能对另一个场景完全没影响(例如，内存密集型视频处理任务比在Word中编辑文档更有可能受到20%内存使用跟踪活动的影响。

注意：如果您在Windows 8 x64之前的系统上使用WPR使用包含堆栈收集的配置文件收集测量，则可能会要求您禁用执行代码的分页。接受该要求，因为它不会对您的系统产生可衡量的影响（这在系统具有MB而不是GB系统内存时很重要）。在旧版本的Windows中，翻转此开关是必要的，以确保堆栈收集不会对系统进行错误检查，因为堆栈行走实现需要访问的一些内核代码可能会被分页。从Windows 8起，x64堆栈漫步已更新为不需要禁用执行代码分页（译者注：balabala没细看，个人仅关注windows10之后）。

当内存中的记录发生时，WPR，或者更确切地说，ETW子系统，以循环的方式使用分配的缓冲区来记录事件。当缓冲区被填满时，较新的事件开始覆盖圆圈中最早的事件。缓冲区越大——可以容纳的事件就越多——并且可以在生成的日志中捕获更长的尾随时间间隔。一旦性能问题被重现，用户需要点击保存按钮，该按钮将记录的事件从缓冲区捕获到跟踪文件。

注意：WPR实际上并不是负责所有跟踪的人。相反，WPR仅提供ETW跟踪控制功能，允许您启用和禁用各种providers程序，然后将其跟踪活动指向ETW会话。这在WPR GUI中不太能体现，因为关闭应用程序将停止录制。不过，一旦我们查看了WPR的命令行版本，您就会发现，即使WPR的实例没有处于活动状态，记录实际上也会继续。

点击保存按钮后，WPR提供将跟踪文件保存在用户文档文件夹下的WPR文件文件夹中，如图3.3所示。

文件名是使用计算机的名称和捕获它的日期/时间自动生成的。当然，您可以自定义文件名及其位置。而且界面鼓励用户填写问题的可选说明（详细描述）。这对于向分析师传达问题是什么非常有帮助。即使您是分析师，我们仍然建议您在捕获时填写此说明，因为不久之后，系统上记录的日志数量就会增长到您无法记住哪个日志代表了什么问题的程度。

在决定了文件名、其位置和问题描述之后，我们接下来需要再次点击保存按钮。然后，WPR将内存中的日志记录持久化到请求的跟踪文件中，如图3.4所示

注意：请注意窗口底部的警告消息。ETW文件在分析中非常有用，因为它们包含许多系统活动的记录。这在定位根因上非常有帮助，但也可能是隐私问题。虽然ETL跟踪通常不包含实际数据，例如文件的内容。但文件名、路径名、进程名等内容，和完整的命令行会被记录。这就是为什么WPR默认情况下将跟踪保存在只有用户（和系统管理员）才能访问的位置。从那一刻起，由用户决定要与谁共享日志。

根据缓冲区的大小、系统（特别是辅助存储设备）的速度以及您运行的托管应用程序，这可能需要几秒钟到几分钟的时间。最终完成后，您将看到一个类似于图3.5所示的视图。

注意：托管应用程序可能会对日志保存时间产生相当大的影响。为了更好地了解此成本的来源，请考虑与本机执行的代码不同，托管代码在运行时编译，因此解码其调用堆栈所需的符号也必须在运行时生成。这些符号存储在与日志文件同名的文件夹中，您可以随时移动日志文件。我们将在第6章中详细讨论符号以及如何在WPA中使用它们。

此时，您有三个选项，也如图3.5：

• 在WPA中打开新捕获的日志

• 打开日志所在文件夹

• 回到主界面

注意：如果您使用了WPR的早期版本（例如，从Windows 8.0时间框架），您会发现只需单击一下即可在WPA中打开新捕获的跟踪的能力非常有用。

我们将花这本书的大部分时间打开WPA中捕获的日志。现在，让我们回到过去，看看使用WPR还能实现什么。

简单的 vs 详细的（Light vs. Verbose）

启用大量的仪器可能是有代价的。根据启用的providers程序，您可能尝试记录的各种活动或交互的持续时间可能会在生成的记录中受到日志记录开销的影响。不幸的是，有时，您有时又恰恰需要这些额外的细节才能从根本上解决问题。

要管理额外日志记录对测量准确性的影响，我们需要了解我们的跟踪对我们正在测量的场景的影响程度，并确保这种影响得到适当管理。这样做的一种方法是捕获两种类型的跟踪：时间跟踪和分析跟踪。

在时间跟踪中，启用了最小的检测，允许您测量持续时间和可能的一些基本资源利用率，但其他的细节不多。然后，您可以将这些持续时间与从分析跟踪获得的持续时间进行比较，分析跟踪启用了根因分析所需的所有测量。

注意：性能测试自动化中的一种常见做法是收集相同工作负载的时间和分析跟踪。然后，分析师使用时间跟踪来评估感兴趣活动的持续时间，并且仅在这些持续时间未能达到时间跟踪中的目标时查看分析跟踪。

WPR通过支持记录Light 和 Verbose两种级别的开关，实现对时间和分析跟踪的支持。您可以通过在“详细信息级别”下拉列表中选择适当的选项，在WPR GUI中选择所需的录制详细程度，如图3.6所示

正如我们将在本章后面看到的，在命令行WPR中，您实际上可以为每个配置文件显式指定记录详细程度。

一般来说，Light记录应用于时间跟踪，而Verbose应用于分析跟踪。也就是说，如果您启用了太多的Light配置文件（通过“细节级别”下拉列表中的Light设置选择），您仍可能在系统上造成大量开销，从而使您的测量不准确。

注意：对于一些内置配置文件，Light与Verbose仅意味着堆栈是否在相关事件上收集。但是，对于其他配置文件，详细模式还启用了额外的关键字标志，甚至是额外的提供程序，这将导致收集全新的事件。

注意：WPR的内置配置文件继承自内部基本配置文件，其中Light和Verbose具有不同的基本配置文件。尤其要注意的是，详细的基本配置文件包括对托管和JScript代码的支持，当您查看托管和JS组件中的调用堆栈时，这是很必要的。

注意：如果您一直在使用xperf.exe捕获性能跟踪，则您错过了WPR中的测量改进，包括JS和.NET符号元数据的收集，以及改进的运行管理。虽然某些高级跟踪控制功能仍然只能通过xperf.exe提供，但WPR完全涵盖了大多数性能跟踪需求。

内置的WPR配置文件（Built-in WPR profiles）

正如我们提到的，WPR的主要工作是让您使用相应的录制配置文件启动和停止性能录制。所有关于测量内容和如何测量的说明都合并在这些配置文件中。当我们之前按下开始按钮时，我们实际上要求WPR做的是使用WPR的内置配置文件开始录制

事实上，WPR附带了一套全面的内置录制配置文件，您可以使用这些配置文件从任何Windows系统收集重要的测量值。

注意：在撰写本书时，WPR在Windows Phone上不可用。从Windows Phone 8.1开始，您可以使用Field Medical应用程序（可从Windows应用商店获得）在Windows Phone上捕获ETL跟踪。然后，您将能够将生成的ETL跟踪复制到Windows计算机，并使用WPA打开它们。

这些配置文件可从WPR的GUI和命令行版本中获得（我们将在本章后面详细讨论命令行版本）。要访问内置配置文件，您需要通过单击更多选项按钮将WPR切换到其高级模式。展开的窗口将如图3.7所示。

如您所看到的，内置配置文件被划分为三个不同的组：

• 一级分类（First Level Triage）：包含单个配置文件，该配置文件涵盖了有助于大多数初始性能分析的基本测量集

• 资源分析（Resource Analysis）: 包含一系列配置文件，这些配置文件可用于对特定于相应硬件/软件资源使用的问题进行自下而上的根本原因分析

• 场景分析（Scenario Analysis）：包含一系列配置文件，这些配置文件可用于自上而下分析特定于执行相应用户场景的问题的根本原因

默认情况下，WPR选择一级分类配置文件。事实上，这就是我们在以前的录制会话中按下“开始”按钮时不知不觉中启用的内置配置文件。

如果您扩展其他两组，您将发现第一级分类配置文件只是冰山一角。在Windows中，您可以测量更多!为了让事情变得更有趣，您实际上可以将多个配置文件组合在一起，以同时测量多种类型的活动。例如，您可以启用磁盘I/O和文件I/O，以在同一跟踪中捕获磁盘和文件系统级别的活动。

一个非常常见的性能测量工作流包括启用第一级分类配置文件以及一个或多个附加配置文件，以获得对系统上特定活动的更详细的见解。请注意，您必须小心仅启用您需要的内容。避免同时启用太多配置文件，因为这可能会影响录制的质量，如果太过分，可能会影响系统本身的可用性（由于录制开销）。

请注意，WPR会记住您在上次录制会话中选择的配置文件，并在启动时恢复它们。如果您有一组自定义配置文件，您希望保持启用，这将非常方便。接下来，让我们仔细看看提到的三个配置文件类别中的每一个

一级分类配置文件（First Level triage profile）

第一级分类类别包括具有相同名称的内置配置文件。WPR在首次启动时默认启用此配置文件。

注意：除非您认为启用第一级分类配置文件会对测量质量产生重大影响，否则通常最好启用它，因为它提供了有关系统上活动的广泛有用信息。

另外，第一级分类配置文件收集以下重要测量值：

• UI delays - 窗口应用程序未及时处理消息的时间间隔(详见第4章)

• 焦点窗口（Windows in focus） - 关于哪个窗口在什么时间点处于前台的信息（详见第4章）

• 进程和线程生命周期（Process and thread lifetimes）–进程和线程创建和终止的时间线（有关详细信息，请参见第4章）

• 二进制文件加载/卸载（Binary image loads/unloads）–可执行映像加载和存卸载的时间线

• 采样的CPU使用率（Sampled CPU usage）–通过记录（在高频下）CPU繁忙执行的内容获得的CPU使用率信息（有关详细信息，请参见第5章和第6章，以及有关深入讨论的第7章）

• 属性CPU使用率(译注：不会翻译)（Attributed CPU usage）–通过跟踪执行线程之间的所有上下文切换获得的CPU使用率信息，包括操作系统做出的调度决策（有关详细信息，请参见第5章和第6章，以及有关深入讨论的第8章和第9章）

• 中断CPU使用率（Interrupt CPU usage）–处理软件和硬件中断所花费的CPU时间（详细信息请参见第9章）

• 基本CPU电源管理活动（Basic CPU power management activity）–有关CPU频率限制和电源状态之间转换的信息

• 单个磁盘IO(Individual disk I/Os) -- （不包括实际传输的数据）–有关系统内启动的每个磁盘I/O的信息（有关示例，请参见第5章，有关详细讨论，请参见第10章和第11章）

• 硬件缺页（Hard faults）–有关导致磁盘I/O的每个页故障的信息（页故障是由于内存访问内存中丢失的数据而导致的磁盘之旅）

第一级分类还收集了系统上发生的一些额外测量值，但我们在这里列出的测量值是最突出的，也是您在分析过程中可能使用的测量值

针对一级分类，VerBose增加了CPU栈信息（包括sampled+attributed）

在这本书中，我们将向您展示如何在动手分析中利用这些测量中的大多数数据。一旦您熟悉相应的分析技术，您将能够将您的覆盖范围扩展到WPR和WPA提供的其他分析领域。

内置资源分析模板配置(Build-in resource analysis recording profiles)

内置配置文件的下一部分包含帮助您测量系统上不同资源使用情况的配置文件。这些资源中的一些是实际的物理实体（例如CPU、磁盘、网络、GPU等），而另一些是逻辑或虚拟实体（例如文件、注册表、堆、池等）。图3.8显示了WPR的Windows 8.1 SDK版本中包含的资源分析配置文件列表

让我们快速查看一下这些配置文件：

• CPU使用情况（CPU usage）-- 采样和属性CPU(sampled and attributed)使用情况的组合。第一级分类的一部分，也单独提供，以仅捕获CPU使用信息（有关详细信息，请参见第5章到第9章）

• 磁盘IO使用情况（Disk I/O usage) -- 有关系统内启动的每个磁盘I/O的信息，不包括实际传输的数据（有关详细信息，请参见第5、10和11章）

• 文件IO活动（File I/O activity）-- 有关系统内启动的每个文件I/O的信息，包括磁盘I/O，文件系统缓存，或者过滤驱动程序。

• 注册表IO活动(Registry I/O activity) -- 每个访问系统注册表子系统的动作，例如SetKey,SetValue,QueryKey,QueryValue等等。

• 网络IO活动（Networking I/O activity) -- 被网络栈处理的每个网络操作，例如发送，接收，连接，断连，回应，等等。

• 堆使用情况（Heap usage）-- 有关使用标准windows堆的特定进程的每个堆分配和释放的信息。

• 池使用情况（Pool usage）-- 有关系统上进行的每个池分配和取消分配的信息，包括分页系统池和非分页系统池

• 虚拟分配使用情况（VirtualAlloc usage）--使用VirtualAlloc(Ex)/VirtualFree Win32 API或其代理在系统上进行的每个虚拟分配和取消分配的信息

• 电源使用情况（Power usage） -- 有关电源管理的信息（详细程序因系统而异）

• GPU活动（GPU activity）-- 通过跟踪计划在系统GPU上执行的所有DMA缓冲区获得的有关GPU使用情况的信息，包括Windows图形子系统（例如DirectX）级别的更高级别的活动

• 句柄使用情况(Handle usage) -- 被OS对象管理器管理的句柄的创建和关闭信息（比如文件句柄、对象句柄、进程句柄等）

• XAML活动（XAML activity）– 有关Windows XAML活动的信息（例如布局、渲染等），在构建在XAML平台之上的Windows应用程序中有用

• HTML活动 （HTML activity）– 有关HTML5活动（例如布局、渲染等）的信息，在构建在Windows Web Apps (WWA)平台之上的Windows应用程序以及托管在Chakra JS引擎之上的常规HTML5/JS应用程序（例如Internet Explorer）

• 桌面合成活动(Desktop composition activity) –有关桌面窗口管理器（DWM）合成活动的信息，负责呈现Windows桌面的每一帧
  

内置场景分析模板配置（Built-in scenario analysis recording profiles）

最后，但并非最重要的部分，内置场景分析模板包含帮助您测量系统上特定于场景的活动的配置文件。图3.9显示了Windows 8.1 SDK版本WPR中包含的场景分析配置文件列表

• 音频毛刺 -- 有关音频堆栈检测到的音频毛刺的信息

• 视频故障–图形堆栈检测到的视频故障（例如错过VSync的帧显示）的信息

• Internet Explorer –有关Internet Explorer活动的信息，包括高级用户交互以及基础子活动，如布局和渲染。

• 微型过滤器I/O活动–有关微型过滤驱动程序级别的I/O活动的信息（例如防病毒）

• XAML应用程序分析– XAML活动+响应性分析所需的信息（第一级分类+ GPU活动+桌面合成活动）

• HTML应用程序分析--HTML活动+响应性分析所需的信息（第一级分类+GPU活动+桌面合成活动）

表3.3按区域对这些项进行了分组，并突出显示了它们的简略信息和详细信息之间的关键差异。

自定义的WPR配置

当然，内置配置文件不能涵盖所有可能的记录场景。虽然他们的覆盖范围很大，但新的Providers一直在出现。其中一些可能是您自己的自定义提供程序，永远都不会得到内置配置文件支持。

您实际上可以编写自己的ETW providers程序来记录自定义事件。因此，您必须能够指定希望在性能测量中启用的其他提供程序。WPR通过WPRP录制配置文件(WPRP recording profiles)的概念支持这种急需的可扩展性。内置配置文件实际上只不过是作为资源内置到应用程序中的WPRP配置文件的实例

您可以在互联网上找到有关如何添加自己的ETW事件的信息。对于C/C++，请在Web上搜索“事件跟踪(Event tracing)”和“编写基于清单的事件(Writing Manifest-based Events)”，您应该在Microsoft网站上找到文档。对于C#，搜索为ETW提供.NET支持的“EventSource”。

收集对的数据

正如您在性能工作期间可能会观察到的那样，Windows在几个关键区域中进行了检测，在某些情况下，这些区域可能在它们提供的跟踪数据方面存在逻辑重叠。这意味着您通常可以使用不同类型的手段分析同一活动。事实上，您选择的手段通常取决于您关注的场景类型。

使用不同的跟踪选项，您可以获得对给定活动的不同视角。请注意，并非所有这些观点都对造成特定问题的根源同样有效。随着后续学习，你将学会为工作挑选合适的工具。

例如，考虑可以使用WPR测量的文件I/O和磁盘I/O活动。文件I/O将显示（除其他外）该文件中的每个文件读写以及目标偏移。您还将看到其他文件系统特定的活动，如文件的创建和删除、目录的枚举、扩展文件信息的查询和修改等。相反，磁盘I/O测量将显示使其进入存储设备的每个读写操作，以及目标磁盘偏移量（而不是文件偏移量）。两者都可用于整体分析存储访问模式，以及针对特定应用程序或文件集分析存储访问模式。同时，这两个测量提供了对同一活动的不同视图。

在大多数情况下，要确定辅助存储设备的争用和饱和情况，使用磁盘I/O活动测量就足够了。不过，这样的视图忽略了系统上发生的许多文件I/O活动，而这些活动从未到达磁盘。比如包括通过文件系统缓存满足的I/O以及文件系统特定的操作，如文件锁定。在某些情况下，获得这种可见性水平可能很重要。我们需要查看文件I/O活动的分析场景的一些常见示例包括：

• 知道我们最终将多少数据写入压缩文件夹
• 了解实际读取的数据量与应用程序请求的数据量
• 了解对磁盘的无效访问模式是由应用程序中的文件系统碎片还是非顺序访问模式引起的
• 分析文件系统驱动程序的活动，例如作为近乎实时防病毒、数据加密或数据压缩工具的一部分的驱动程序等

最终，有时您只是想更好地处理应用程序的意图，而不是系统最终做的事情

记录模式

WPR支持两种可用于性能测量的日志记录模式：

• 内存 --数据记录到内存的一块循环buffer中
• 文件 -- 事件记录到一个序列化的文件中
  

默认情况下，选择内存记录模式，因为对于大多数典型的用户场景（和内置WPR配置文件），此模式通常会产生比直接记录到顺序文件收集的跟踪更高质量的测量（除非目标系统内存不足）。它背后的主要原因来自文件记录模式会产生污染——跟踪中涉及的磁盘I/O与作为测量场景一部分的I/O竞争，可能会严重减缓执行速度。请记住，对辅助存储设备的访问比对物理内存的访问慢数量级，因此将所有日志记录成本限制在CPU和内存上听起来是一个精明的策略（同样，除非您的内存不足）。当然，这两个世界中最好的做法是将一个单独的物理存储设备专用于日志记录任务，因为在这种情况下，用于跟踪的内存很少，系统驱动器也不会产生争用。不幸的是，这样的奢华并不总是一种选择。

使用内存日志记录模式，根据选择的配置文件，将为保存ETW事件的循环缓冲区分配相应的系统内存量。具体来说，第一级分类配置文件分配5%的系统内存用于跟踪——对于大多数客户端甚至某些服务器场景来说，可以忽略不计。同时启用第一级分类和磁盘I/O活动，您现在将花费11%的系统内存——这是一个更大的物理内存块，特别是当您的系统有大量内存时。

注意：所有内置的WPR配置文件都使用一定百分比的系统内存进行分配，但在创作自己的WPR配置文件文件时，您也可以指示显式缓冲区大小。

给定足够的可用内存，内存日志记录模式可确保性能测量开销最小。当然，如果我们试图测量内存密集型工作负载并在低内存条件下运行，或者希望捕获比循环内存缓冲区中适合的时间跨度更长的时间跨度，我们可能不得不被迫切换到文件日志记录模式。

在文件日志记录模式下，启用一级分类和磁盘I/O活动仅消耗约80MB的系统内存。这些记录的事件不会登录到内存日志记录模式使用的临时缓冲区，而是直接流式传输到存储设备上的文件。好处是，我们的测量不太可能导致内存压力——即导致系统开始耗尽内存。正如我们刚才提到的，缺点是，由此产生的日志记录I/O可能会严重干扰测量场景的任何I/O，这些场景碰巧共享同一辅助存储设备。

默认情况下，WPR跟踪到系统驱动器（通常是驱动器C:），但您可以使用WPR –start –filemode [-recordtempto <temp folder path>]选项从命令行控制此操作。如果有足够快的辅助存储设备，您可能可以直接记录到系统的驱动器，但对于一些低功耗超薄设备，这样做可能会对感兴趣的场景产生重大影响。对于此类情况，我们建议您使用专用的辅助存储设备进行测量

注意：在我们作者的经验之一中，在I/O繁重的场景中启用详细日志记录会导致总体场景卡慢高达20%。经常尝试将场景的端到端持续时间从定时跟踪（即极简测量）与分析跟踪（丰富测量）进行对比，以确保您的测量不会影响您试图测量的场景。

在本书中，我们使用WPR GUI和WPR命令行工具的组合来记录性能测量。要了解我们如何利用WPR的命令行版本，您可能需要查看下一节。否则，请跳过它，进入下一章书的分析部分。

WPR命令行工具

任何能够在WPR GUI中执行的操作，您也同样可以使用其命令行工具完成，其可执行文件简单地命名为wpr.exe。在我们的前几个练习中，我们依赖于GUI版本，但随着我们对性能测量的更加熟练，我们将在跟踪捕获中广泛使用命令行版本。毕竟，脚本有助于使我们的性能测量方法更加高效和确定性，这是正确实施的自动化质量保证工作流的一个重要方面。

与大多数命令工具一样，要查看支持的选项列表，只需在没有任何命令行参数的情况下运行wpr（您也可以通过运行wpr –help来访问此列表），如图3.11所示

在以下各节中，我们将介绍WPR中一些最常用的命令，其余的供您探索。任何时候有疑问，请依靠wpr –help <command>了解详细信息

列出内置选项（Listing build-in profiles）

要列出WPR附带的内置配置文件，请使用wpr -profiles，如图3.12所示

请注意，与WPR GUI不同，命令列表不会按资源和特定场景的测量对内置配置文件进行分组。尽管如此，还是很容易找到我们在图3.8和图3.9中展示的所有相同配置文件

另请注意，第一级分类实际上从命令行中称为GeneralProfile。其他内置配置文件的命名类似于其GUI名称

检查配置文件定义(Examining profile definition)

要查看配置文件的详细信息，请使用wpr -profiledetails选项，如图3.13和图3.14所示，

比如查看常规配置文件的详细信息，执行wpr -profiledetails GeneralProfile

请注意，您无法从WPR GUI获得此级别的详细信息。大多数人不需要查看此信息，但如果您想确切地知道为给定的配置文件启用了哪些ETW提供程序，使用哪些标志和关键字，将分配多少跟踪缓冲区，以及每个缓冲区的大小，这就是您如何为内置配置文件找到它。使用自定义WPR配置文件，您可以直接在WPRP文件中查找这些详细信息，也可以在该WPRP文件上使用WPR –profiledetails命令。

记录性能跟踪(Recording a performance trace)

WPR中最重要的任务是记录性能跟踪——您可以使用wpr -start命令。让我们尝试使用GeneralProfile开始录制性能跟踪

请注意，如果WPR GUI仍在运行，您将看到如图3.15所示的WPR错误，报告重复实例的错误。这是由于WPR的限制，如果WPR GUI正在运行，则不允许对跟踪进行任何命令行操作

正如我们提到的，wpr.exe和wprui.exe只是同一底层引擎的两个前端。此引擎称为Windows性能录制控制（WPRC）引擎，从Windows 8.1 SDK起，一次只支持其客户端的一个实例

注意：Windows评估和部署工具包（ADK）中的各种评估也使用WPRC进行跟踪捕获。由于单例客户端要求，在执行ADK评估时WPRUI不能处于活动状态，反之亦然

关闭WPR UI并尝试再次运行相同的命令，我们仍然会遇到失败，这一次抱怨缺乏足够的权限，如图3.16所示。

不出所料，WPR需要管理权限来记录跟踪。这是WPRUI为我们处理的事情——即，无论何时您以普通权限启动WPR GUI，它都询问并提升权限。

注意：全局ETW会话的跟踪控制要求提升权限。 ETW确实支持范围为不需要提升的单个进程的专用ETW会话，但WPR在撰写本书时并不提供对此类会话的控制

让我们尝试从提升的命令提示符运行相同的命令。在这最终成功后，我们可以使用wpr –status命令检查录制的状态，最后停止录制并使用wpr –save将跟踪保存到ETL文件中，如图3.17所示。

请注意，就像GUI版本一样，您需要指定跟踪文件名以及要在该跟踪中捕获的性能问题的描述。另请注意，wpr -status不会告诉您哪个配置文件正在用于录制。我们马上就教你怎么看。

默认情况下，WPR使用配置文件的Verbose选项（如果可用）。就像GUI版本一样，您可以在Light和Verbose配置文件之间进行选择。为此，请通过将.Light或.Verbose附加到配置文件的名称后，显式指定所需的变体。例如，要启动GeneralProfile的Light变体，请使用wpr–start GeneralProfile.Light，如图3.18所示。您可以使用WPR –status命令确认录制正在进行中。还可以加上-profile选项，它将显示正在录制的配置文件

如果您决定最终不想将录制保存到文件中，您可以使用wpr -cancel停止录制并取消收集的数据。这两个命令也显示在图3.18中。

使用多个配置文件（Using multiple profiles）

请记住，在WPR GUI中，您只需选中多个复选框，就可以将多个配置文件组合在一起。同样的事情也可以从命令行中进行。为此，您只需要启动您感兴趣的所有配置文件。例如，图3.19显示了如何一起启动第一级分类、磁盘I/O和网络I/O配置文件

wpr -start GeneralProfile -start DiskIO -start Network

在图3.13和图3.14中，我们已经看到了如何查看特定WPR配置文件的定义。要查看多个启动配置文件的联合，我们可以使用wpr -collectors，如图3.20和图3.21所示

注意：添加-details将包括一些其他信息，例如为每个ETW会话分配的跟踪缓冲区数量。

此命令列出由启动的配置文件启用的所有provider程序。它向我们展示了内核provider程序以及已启用的其他用户provider程序。回想一下ETW事件已记录由称为ETW提供程序的逻辑实体。这些提供程序由其相应的所属组件在系统上注册。然后，任何ETW跟踪控制实用程序，如WPR，都可以向Windows指示它希望从一个或多个此类ETW提供程序接收事件。

wpr -status collectors -details

注意：在不同品种的系统上有许多不同的ETW提供商。ETW最初是出于Windows 2000中提供诊断的需要。总共支持32个并发跟踪会话，其中一个是专门用于内核的特殊会话，也称为“系统跟踪提供程序(System Trace Provider)”。此会话称为“NT内核记录器(NT Kernel Logger)”，此名称在最新版本的Windows中一直使用。其他会话可用于系统上也希望公开诊断信息的任何组件。人们可以创建记录到这些会话的其他提供程序，称为“用户”提供程序(User providers)，不要与用户模式混淆，因为这些提供程序可以生活在用户或内核模式代码中。这些提供程序今天在系统中通常被称为经典提供程序（Classic providers）。

注意：“用户”一词的用法可能会让您感到惊讶，因为一些所谓的“用户”提供程序实际上是内置系统组件。此术语来自以内核为中心的操作系统视图（ETW源自Windows中的核心操作系统团队），他们将将系统上除内核以外的所有组件视为内核的用户。

当启用多个跟踪配置文件时，保存跟踪（如图3.21所示）的工作方式与单个配置文件录制的工作方式完全相同（即wpr -stop）。WPR（或者更确切地说，WPRC）记住启动了哪些配置文件，并停止这些配置文件。录制正在进行时，所有其他开始录制的尝试都会失败，如图3.22所示

总结

回顾一下我们学习至今的收获：

• 在引入WPR之前（很老版本的windows），您必须知道要启用哪些提供程序、要使用哪些标志和关键字、要分配多少缓冲区以及要使用哪些缓冲区大小

  • 所有这些实质细节现在都安全地封装在WPR配置文件中，为您留下重要的内容——实际性能分析

• WPR提供了丰富的内置测量配置文件，让您可以测量任何现代Windows系统上感兴趣的活动

  • WPR提供了丰富的内置录制配置文件，让您可以测量任何现代Windows系统上感兴趣的活动
  • 这些配置文件的Light选项对于深入了解各自活动的时间线非常有帮助
  • Verbose选项提供了对这些活动期间发生的事情以及谁发起这些活动的丰富可见性
  • 内置记录配置文件在不断变化。

• 由于本书侧重于介绍性通用性能分析，我们将注意力集中在理解关键系统资源的使用上

  • 最终，通过使用这些关键资源查看系统活动，可以诊断大多数性能问题
  • CPU、磁盘和内存情况配置文件通常是对最常见性能问题进行第一级分类和根本原因分析所必需的
    • 这就是为什么它们被包括在第一级分类内置配置文件中的原因

• 要帮助调查特定问题域，您可以利用WPR中包含的其他内置配置文件

  • 他们将帮助您提供诊断所发生的事情所必需的上下文
  • 在其他情况下，它们将通过提供特定于您感兴趣场景发生的逻辑活动的属性来简化您的分析