c# - 性能问题 : A case study comparing multi-threading versus multi-processing

Question

1. 硬件:我们使用 24 核(2*12 核)机器。 SSD 磁盘和 SAS-RAID 0 磁盘有 2 个独立的 Controller 。操作系统:Windows 8.1。超线程已禁用。

2. 软件:

   2.1。有一个 master 为 workers 填充工作队列，然后从结果队列中收集结果。

   2.2。有 n 个工作人员从工作队列中检索工作。他们将小的输入文件写入磁盘并启动外部进程来执行实际计算。外部进程完成输出后，大小为 10-15 MB 的文件需要从文件系统中读入并进行相应的解析。最后，工作人员将结果放入结果队列并继续处理工作队列中的下一项。

3. 利用两个磁盘对文件系统的访问在工作进程之间平均分配。

4. 观察

   4.1。从 0 到 10 worker，多线程和多处理几乎呈线性加速。从 10 增加到 28 worker 在多处理的情况下有合理但次线性的加速，但在多线程的情况下几乎没有增加。 p>

   4.2。我们对多线程进行了广泛的计时，发现计算时间几乎保持不变，当增加工作人员数量时，增加的时间可以忽略不计。 相比之下，当工作人员的数量从 10 增加到 40 时，从磁盘读取文件的时间急剧增加并导致核心进入空转。

   4.3。在多处理的情况下，worker 似乎能够正确地充分利用两个独立的文件 IO channel (RAID 和 SSD)，并且远远优于多线程。

最后一个问题:多线程的瓶颈是什么，我们如何绕过它？

注意 1:完全避免文件系统访问不是一种选择，因为外部进程是第三方软件。

注意 2: 我知道这些 answers ，但他们没有解决我的问题。

2019 年更新 在另一台配备 18 核和 Windows 10 的机器上，我们观察到完全相同的行为。

Answer 1

Multiprocessing 是否比 Multithreading 更有优势，反之亦然很大程度上取决于您使用的具体代码和您的环境，因此很难得出什么结论完全没有看到有问题的实际代码和详细的测量结果(响应时间、CPU、磁盘、内存性能计数器值等)。

从您分析的4.2. 和4.3. 点来看，您的 CPU 和 IO 似乎没有得到正确利用。如果您正确地执行了多处理和多线程方案，那么在性能上应该没有任何显着差异。 CPU 空闲和读取时间增加可能表明代码中存在线程阻塞问题，这可能会影响可扩展性和性能。

确保您没有阻塞同一进程内共享资源上的线程，这可能会影响多线程场景中的性能。此外，在处理队列和文件时，您应该利用非阻塞异步 IO 以确保最大。并发。

您应该记住，您的应用程序中并发工作线程的最佳数量是 24(每个内核一个线程)，超过该限制可能不是一个好主意，除非测量证明您错了。

CLR 线程池使用核心数作为默认线程池的最小值，这意味着当您的应用使用 <= 24 个线程时，您不会有性能损失。但是，当您安排超过 24 个并发作业时，线程池将开始定期将线程注入(inject)线程池以服务超过 Min.Limit 的任务。在 .NET framework < 4.0 中，这是每 0.5 秒 1 个线程的速率。在 .NET 4.0+ 中有一个并发抑制算法，但它仍然不是最优的。