Windows CPU 调度程序 - 非常高的内核时间

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

5年前关闭。




Improve this question




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

背景资料

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

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



上面的服务器运行“主机”约 500 个进程(作为 Windows 服务)，这些“主机”进程中的每一个都有一个内部 while 循环，延迟约 250 毫秒(哎呀!)，每个“主机”进程可能有~ 1..2 正在执行实际工作的“子”进程。

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

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

但是，在我们调查此问题时，我们进行了一些 xperf 分析，其中提出了几个有关 Windows CPU 调度程序的一般性问题，我们无法找到任何清晰/简明的解释。

我们不明白的地方

下面是来自 xperf session 之一的屏幕截图。



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

有 15 毫秒的时间片，其中大部分未被充分利用。这些切片的利用率约为 35-40%。所以我假设这反过来意味着 CPU 大约有 35-40% 的时间被利用，但系统的性能(假设通过对系统的随意修补可以观察到)是 真是呆滞 .

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

一些 CPU 显然用于整个 15 ms 切片及更长的时间。

问题

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

什么导致 30% 的内核成本？上下文切换？还有什么？编写应用程序时应考虑哪些因素以降低此成本？甚至 - 以最小的基础设施成本实现完美的利用率(在多处理器系统上，进程数高于内核数)

这些 15 毫秒的切片是什么？

为什么 CPU 利用率在这些切片中存在差距？

Answer 1

要诊断 CPU 使用率问题，您应该使用 Windows 事件跟踪 (ETW) 来捕获 CPU采样数据(不精确，这对于检测挂起很有用)。

要捕获数据，install the Windows Performance Toolkit ，它是 Windows SDK 的一部分.



现在运行 WPRUI.exe ，选择 First Level , 在资源下选择 CPU使用率然后点击 开始 .



现在捕获 1 分钟的 CPU 使用率。 1 分钟后点击 保存 .

现在 analyze the generated ETL file with the Windows Performance Analyzer通过拖放 CPU Usage (sampled)图到 analysis pane并像您在图片中看到的那样对列进行排序:



WPA内部，load the debug symbols并展开系统进程的堆栈。在这个演示中，CPU 使用率来自 nVIDIA 驱动程序。