windows - Windows CPU Scheduler - 内核时间非常长

我们正在努力了解Windows CPU Scheduler如何工作以优化我们的应用程序，以实现最大可能的基础架构/实际工作比率。在xperf中有一些我们不理解的东西，并且想要让社区了解真正发生的事情。当我们收到有关某些服务器“缓慢”或“无响应”的报告时，我们最初开始调查这些问题。

背景资料

我们有一台运行我们的中间件基础架构的Windows 2012 R2 Server，其规格如下。

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

上面的服务器运行“主机”~500个进程（作为windows服务），这些“主机”进程中的每一个都有一个内部while循环，延迟时间约为250毫秒（yuck！），以及每个“主机”进程可能有~1..2“子”进程正在执行实际工作。

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

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

然而，在我们调查这个问题的时候，我们已经做了一些xperf分析，提出了几个关于Windows CPU Scheduler的一般性问题，我们无法找到任何明确/简明的解释。

我们不理解的内容

以下是其中一个xperf会话的屏幕截图。

您可以从“CPU使用率（精确度）”中看到

有15毫秒的时间片，其中大部分未充分利用。这些切片的利用率约为35-40％。所以我认为这反过来意味着CPU大约有35-40％的时间被利用，但系统的性能（假设通过系统周围的随意修改可以观察到）真的很迟钝。
有了这个，这个“神秘的”30％内核时间成本，由任务管理器CPU利用率图判断。
显然，有些CPU用于整个15 ms以及更长时间。

问题

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

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

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

的一部分

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

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

现在analyze the generated ETL file with the Windows Performance Analyzer通过拖放＆amp;将CPU Usage (sampled)图表拖放到analysis pane并按照图片中的顺序排列列：

在WPA内部，load the debug symbols并展开SYSTEM流程的Stack。在本演示中，CPU使用率来自nVIDIA驱动程序。