多核环境中的多线程应用程序 - 每个内核的负载很奇怪

Question

给定环境：16 核 Xeon 处理器，操作系统 - Win 2008 server R2。

给定应用程序 (.Net/C#) 在并行加载 1 个内核之前几乎 100%。 获得一些利润的明显解决方案是使用 .Net 4 并行任务库来加速应用程序 X 倍。 假设应用程序的并行部分真的很合适——线程之间没有发生锁定（没有共享资源，每个并行任务是完全独立的）。 但令我遗憾的是，利润非常低 - 16 线程应用程序大约可以工作。比顺序快 2 倍。

这是第一个插图 - 16 个内核上的 16 个线程

这看起来很奇怪 - 每个任务都是相等的，但前 8 个内核的负载几乎相同（~30%），而其他 8 个内核的负载逐渐下降。

所以，我尝试了不同的配置，例如 16 核上的 8 个线程

看起来 8 个线程都在 8 个内核上运行，并且线程不会从一个内核转移到另一个内核。此外，8 核的平均核心负载大于 16 核。

我通过分析器进行了一些研究 - 每个线程在不同方法中花费的时间百分比方面具有与单线程情况相同的行为。唯一（和平均）差异是绝对时间——它随着线程数的增长而变得越来越大（就像每个核心的性能都在下降）

所以我无法解释的主要趋势 - 更多线程意味着每个核心的平均负载更低，整体 CPU 使用率最高约为 20-25%。并且线程中的每个操作都随着线程数的增长而运行得更慢。

有什么想法可以解释这些奇怪的事情吗？

UPD

应用Server GC后画面发生了明显变化

16 核上的 8 个线程插图：

16 核上的 12 个线程插图：

16 核上的 15 个线程插图：

所以，看起来 CPU 使用率随着核心数量的增长而增加。 困扰我的第一件事是它看起来像所有内核都被使用并且线程从内核跳到内核，所以整体性能不是那么好。

第二件事是应用程序的最高速度是 12 核，15 核给出相同的结果，16 核甚至更慢。

可能的原因是什么？

Answer 1

您看到的模式通常表明存在 I/O 瓶颈。如果您的磁盘或网络正在全力运行以向这些计算提供数据（或处理结果），那么您可以在一百万个内核上运行它而没有额外的好处。我建议使用 Sysinternals Process Explorer 检查网络和磁盘 I/O 并查看是否存在问题，然后再尝试进一步了解为什么这不能很好地并行化。

Answer 2

由于听起来您的方法内部没有同步，因此问题可能出在分区中。

鉴于您使用的是 TPL，必须根据分区程序将工作发送到内核。但是，实际源 IEnumerable<T> 不是线程安全的，因此需要通过单核访问。实际上，如果与项目数量相比，实际工作量很小，这通常会导致您在上面展示的性能特征。

解决此问题的方法是使用Partitioner class 将您的工作项预先划分为块，然后并行遍历项目的“块”。详情请见How to: Speed Up Small Loop Bodies。