【发布时间】：2016-08-12 11:58:36
【问题描述】：
我们正在尝试了解 Windows CPU 调度程序的工作原理，以优化我们的应用程序以实现最大可能的基础架构/实际工作比率。 xperf 中有一些我们不理解的东西，希望社区能对真正发生的事情有所了解。 当我们收到一些服务器“缓慢”或“无响应”的报告时，我们最初开始调查这些问题。
背景信息
我们有一个 Windows 2012 R2 Server，它运行我们的中间件基础架构，具有以下规格。
我们发现 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% 的时间被利用，但系统的性能（假设可以通过随意修改系统来观察）真的很慢。。 p>
有了这个，我们就有了这个“神秘”的 30% 内核时间成本，由任务管理器 CPU 利用率图判断。
某些 CPU 显然被用于整个 15 毫秒及更长的时间片。
问题
就多处理器系统上的 Windows CPU 调度而言：
- 30% 内核成本的原因是什么？上下文切换？还有什么？在编写应用程序以降低此成本时应考虑哪些因素？甚至 - 以最小的基础设施成本实现完美的利用率（在多处理器系统上，其中进程数高于内核数）
- 这些 15 毫秒切片是什么？
- 为什么 CPU 利用率在这些切片中存在差距？
【问题讨论】：
-
这是一个问答网站，这意味着通常每个帖子都有一个特定的问题。在某些情况下，几个相关的问题可能是可以接受的。关于操作系统相关而非代码相关的如此广泛范围的六个问题确实推动了事情的发展。 MS 已经记录了调度程序的设计，并在许多 MS 博客文章中进行了讨论。除了在操作系统上运行的程序之外，您所问的任何内容都与任何特定意义上的编程无关。
-
你不会在操作系统之外编写软件。
-
这在很大程度上取决于“工作”进程实际上在做什么。如果没有大量繁重的 CPU 工作（如果您主要在等待 I/O 或其他东西），则可以预期空闲 CPU。同样，如果你的大部分时间都花在了操作系统调用上——尤其是空闲循环——30% 的内核时间似乎并不合理。要获得最佳性能，您需要的进程要少得多。最好只有一个。你没有说你是否正在动态创建工作进程，但如果是这样，你应该注意启动一个进程真的很慢。
-
工作进程被重用，因此如果一个“主机”应用程序有一个“工作”子进程，只要有可用的工作，它就会重用它，然后等待~5新工作来的分钟，如果新工作没有来，进程将被关闭。然而实际上，“工作”进程只是留在那里，因为“主机”有足够的工作让它们“活着”。工作进程执行的东西是 Query->Process->Submit 的混合，因此外部服务 (SQL) 上有一些 IO。如果出现循环，它的哪一部分构成内核消耗？
-
FWIW，我可以给出答案，但由于问题已关闭，因此并不值得。简而言之：CPU 使用率（采样）会告诉您您在内核中花费的时间 - 请注意，这可能会受到 ETW 分析的影响，并且可能并不重要。此处介绍了查找 CPU 空闲的原因：randomascii.wordpress.com/2012/05/05/… Oops，我想我给出了完整的答案。
标签： windows performance context-switch windows-kernel xperf