问题标签 [xperf]

我们正在尝试了解 Windows CPU 调度程序的工作原理，以优化我们的应用程序以实现最大可能的基础架构/实际工作比率。xperf 中有一些我们不理解的东西，希望社区能对真正发生的事情有所了解。当我们收到一些服务器“缓慢”或“无响应”的报告时，我们最初开始调查这些问题。

背景资料

我们有一个 Windows 2012 R2 服务器，它运行我们的中间件基础设施，具有以下规格。

我们发现 30% 的 CPU 浪费在内核上，所以我们开始深入挖掘。

上面的服务器运行“主机”~500 个进程（作为 Windows 服务），每个“主机”进程都有一个内部 while 循环，延迟约 250 毫秒（糟糕！），每个“主机”进程可能有 ~ 1..2 执行实际工作的“子”进程。

虽然在迭代之间具有 250 毫秒延迟的无限循环，但“主机”应用程序执行的实际有用工作可能仅每 10..15 秒出现一次。因此，不必要的循环浪费了很多周期。

我们知道“主机”应用程序的设计至少可以说是次优的，应用于我们的场景。应用程序正在更改为不需要循环的基于事件的模型，因此我们预计 CPU 利用率图中的“内核”时间会显着减少。

然而，当我们调查这个问题时，我们已经做了一些 xperf 分析，它提出了几个关于 Windows CPU 调度程序的一般问题，我们无法找到任何清晰/简洁的解释。

我们不明白的

下面是 xperf 会话之一的屏幕截图。

从“CPU Usage (Precise)”可以看出

• 有 15 毫秒的时间片，其中大部分没有得到充分利用。这些切片的利用率约为 35-40%。所以我假设这反过来意味着 CPU 大约有 35-40% 的时间被利用，但系统的性能（假设通过随意修改系统可以观察到）确实很慢。

• 有了这个，我们就有了这个“神秘”的 30% 内核时间成本，由任务管理器 CPU 利用率图判断。

• 一些 CPU 显然被用于整个 15 毫秒及更长的时间片。

问题

就多处理器系统上的 Windows CPU 调度而言：

• 是什么导致了 30% 的内核成本？上下文切换？还有什么？在编写应用程序以降低此成本时应考虑哪些因素？甚至 - 以最小的基础设施成本实现完美的利用率（在多处理器系统上，其中进程数高于内核数）
  • 这些 15 ms 切片是什么？
  • 为什么 CPU 利用率在这些切片中存在差距？

是否有一个性能计数器来指示特定进程的多少内存被调出？我有一台具有 40 GB 可用 RAM（128 GB 物理内存）的服务器，但分页的数据量超过 100 GB。我怎样才能找出我的哪些进程负责那个巨大的页面文件消耗？

也可以进行一些 xperf 跟踪以查看页面输出活动何时发生。但是除了对页面文件的许多写入之外，我看不到内存是从哪个进程写入页面文件的。

参考集跟踪仅向我展示了我的进程的物理内存消耗有多大。但它似乎没有跟踪页面输出活动。

更新 操作系统是 Windows Server 2012 R2

BitmapImage 的源在 UI 中显示后会自动释放吗？

我看到在 Image 控件中显示一次 BitmapImage 后，再次显示它需要大约 300 毫秒。在此延迟期间，屏幕上没有绘制任何内容。使用 XPerf 进行分析显示了解码操作。解码应该不是必需的，因为图像已经显示。

（顺便说一句 - 我发誓这在 Windows 8 中没有发生，但无法证明）

编辑 - 更多分析...

在一次运行中，250 毫秒的延迟分为 120 毫秒用于解码、100 毫秒用于填充渲染目标和 30 毫秒用于 dwm 将其放在屏幕上。也许是图像控件正在释放渲染目标的内存？

编辑 -

当一个 Image 控件的 Source 被赋予一个新创建的 BitmapImage 时，图像会立即显示在 UI 中。当给定一个之前显示的 BitmapImage 时，大约 300 毫秒没有显示任何内容。使用 XPerf 进行分析表明，这些情况之间的主要区别在于后者需要解码步骤。

我为 BitmapSource 创建了一个代理，希望我可以窃听 Image 控件对位图所做的事情。这没有用。看起来 Image 控件通过一个接口访问图像数据，而不是它要求您提供的接口 (ImageSource)。

我需要编写一个小程序/脚本来运行 Xperf，以通过 Windows 快速启动（又名快速启动）周期收集某些 ETW 事件（操作系统和驱动程序）。

我如何能够保留我的程序和 xperf 进程，以便它们可以收集事件，直到操作系统休眠和操作系统再次初始化？Windows Performance Recorder (WPR) 可以做到这一点，但出于其他原因我需要自己编写。

我为 CLR 提供程序记录 ETW 事件：

然后在 wpa.exe 中打开 clr.etl 并查看大量“通用事件”。但似乎 wpa 不显示一些数据，这在MSDN中有描述

我所看到的都与此类似：

Loo like this is GCStart_V1event，但我找不到例如字段Reason

是否可以在 wpa 中查看通用事件数据？

WPA 版本 - 10.0.10586.212

我尝试使用显示的基本事件来记录事件以进行调试和分析。但是我有一个问题：当我注册我的提供者进行录制时，一切都很好，当在 WPA 中打开 .etl 文件时，我可以查看尽可能多的信息。但是，如果我在未注册提供者的情况下收集事件，当我在 WPA 中打开 .etl 文件时，一切都不是人性化的。那么，我必须在开始收集事件之前注册我的提供商吗？我希望不会，因为如果是这样，我必须冒险泄露我的 .man 文件，所以其他人也可以使用它来获取详细的跟踪日志。这是不可接受的！

我不希望我的 .man 文件打包在安装文件中，所以我不必担心泄漏它。当然我也不能注册我的提供商。

有没有办法尽可能好地查看 .etl（在没有我的提供商先注册的情况下收集）？

提前致谢。

下面的图片可能会使我所说的更容易理解。

未注册我的提供者的记录图像：

我的提供商注册的记录图像：

我们有一个 WPF 应用程序，它偶尔（很少）变得非常缓慢。我们设法捕获了 WPA 跟踪（又名 xperf），它清楚地显示了应用程序活动的滞后 - 同时dwm.exe活动明显增加。

我无法从堆栈中提取任何有用的见解来了解正在发生的事情。该应用程序似乎在以下堆栈中花费了大量时间：

而且 dwm 似乎在下面的堆栈中花费了很多时间：

任何人都可以阐明是什么让应用程序变慢了吗？

编辑： 这是 WPA pkg (350k)，以防您愿意看一看。

我正在捕获 ADO.Net 诊断 ETW，如SQL Server 2008 中的数据访问跟踪中所述。设置有效，生成了一个 ETL 文件，如果我使用tracerpt，我可以看到 ADO.Net 跟踪：

但是，如果我将相同的 ETL 加载到WPA中，我发现捕获的事件没有任何用处。来自此提供程序的所有事件都显示Event Name <Unknown>，Event Type Classic并且没有关于实际 ADO.Net 事件信息的信息（即 tracerpt CSV 输出中最右边的列）：

由于我捕获的所有其他数据都可以在 WPA 中进行分析，所以我想知道 ADO.Net 诊断提供程序有什么不同，即事件对 WPA 如此不透明？

在使用 xperf 分析 Windows 性能时，我收集了跟踪并获得了调用堆栈数据。如果继续深入调用堆栈，跟踪有时会以System\Interrupts + DPCs或结尾System\ETW overhead。

我附上了一个显示相同的堆栈跟踪：

折叠的跟踪再次调用System\Interrupts + DPCs<itself>

这些堆栈条目是什么意思？这里调用了哪些函数？忽略它是否安全（不过，我对此表示怀疑）？

我使用 xperf 将 ETW 捕获到文件中。

正如我设置的那样，它似乎只在-MaxFileLimit到达时才将数据写入磁盘。

我可以设置它以便更频繁地写入文件吗？我希望能够在事件发生后立即获取日志。

LE：我想将跟踪记录到文件中，但也要防止文件超过大小限制。而且我希望能够在不中断记录会话的情况下获取文件的副本以查看最新记录的信息。（目前为了获得有用的信息，我有 2 个选项：停止会话或等待达到 MaxFile）。希望我的意图现在很清楚。