我们试图了解Windows CPU调度程序如何工作以优化我们的应用程序以实现最大可能的基础结构/实际工作率。在xperf中有一些我们不明白的东西，并希望让社区了解真正发生的事情。 当我们得到有些服务器“缓慢”或“无响应”的报告时，我们最初开始调查这些问题。Windows CPU调度程序 - 内核时间非常高
背景资料
我们有我们的运行具有以下规格的中间件基础架构在Windows 2012 R2服务器。
我们发现，有30％的CPU在内核上浪费了，所以我们开始深入挖掘。
上述运行“宿主”〜500个处理（作为Windows服务）服务器，每个这些“宿主”过程的具有内的while循环用〜250毫秒的延迟（呸！），并且每个那些“主机”进程可能有〜1..2个“子进程”正在执行实际工作。
虽然迭代之间有250毫秒延迟的无限循环，但“主机”应用程序执行的实际有用工作可能每10..15秒才会出现一次。所以有很多循环浪费了不必要的循环。
我们知道，“主机”应用程序的设计在应用于我们的场景时并不是最优的。应用程序正在变成基于事件的模型，不需要循环，因此我们期望CPU使用率图中“内核”时间的显着减少。
然而，尽管我们正在调查这个问题，我们做了这引起了有关Windows CPU调度程序，我们无法找到任何明确的/简洁的解释几个常规问题的一些xperf分析。
我们不明白
下面是从xperf会议的一个截图。
您可以从 “CPU使用率（精）” 看到
有15个毫秒的时间片，其中大部分是利用不足。这些切片的利用率是〜35-40％。所以，我认为这又意味着CPU被利用一下〜时间35-40％，但该系统的性能（假设通过该系统围绕休闲修修补补观察到的）是真的低迷。
有了这个，我们有这个“神秘” 30％的内核时间成本，通过任务管理器的CPU利用率图形判断。
一些CPU显然用于整个15毫秒及以上的切片。
问题
至于在多处理器系统的Windows CPU调度而言：
- 是什么原因导致30％的内核成本是多少？上下文切换？还有别的吗？在编写应用程序以降低成本时应该考虑什么？甚至 - 以最少的基础设施成本实现完美的利用率（在多处理器系统上，进程数量高于核心数量）
- 这些15 ms切片是什么？
- 为什么CPU利用率在这些片段中存在差距？
这是* Question and Answer *网站，这意味着每个帖子有一个特定的问题作为一般规则。在某些情况下，有几个相关的问题可能是可以接受的。关于如此广泛的操作系统相关而非代码相关的六个问题实际上是在推动事物发展。 MS已经记录了调度程序的设计，并且已经在许多MS博客文章中讨论过。没有任何问题涉及到任何特定意义上的编程，除了在OS *上运行的*程序之外。 –
您不要与操作系统隔离编写软件。 –
它很大程度上取决于“工作”流程实际上在做什么。如果没有太多繁重的CPU工作（如果你主要在等待I/O或其他东西），那么空闲的CPU是可以预期的。同样，如果大部分时间都花费在OS调用上 - 特别是空闲循环 - 30％的内核时间似乎并不合理。为了*最佳*性能，您需要的流程少得多。最好只有一个。你没有说你是否正在创建工作进程，但如果是这样，你应该注意到启动一个进程真的很慢。 –