我们正在尝试了解 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 利用率在这些切片中存在差距？
