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利用率在这些切片中存在差距？