是否有最大并行任务数量的一般规则？答案

【问题标题】：Is there a general rule for a maximum amount of parallel tasks?是否有最大并行任务数量的一般规则？
【发布时间】：2014-04-25 18:38:04
【问题描述】：

我第一次使用并行任务，而不是使用传统的线程池。在我的应用程序中，我允许用户输入开始完成工作的任务数。（工作可能非常大）。我注意到，如果我允许超过 10 个左右的任务，应用程序就会开始挂起，并且由于使用的资源，我实际上会得到更差的性能。

我想知道处理器数量和最大任务数量之间是否存在任何相关性，以便我可以限制用户电脑的最大任务数量，以免减慢速度。

【问题讨论】：

我想这取决于你的线程在做什么。磁盘 I/O 访问？内存计算？通常，在编译库时，我总是在一台机器上使用最多 2* 数量的处理内核，但通常对于任何内置线程任务，我倾向于坚持使用 1 对 1 与 cpu 内核。
我的一般规则是从 1.5/2 个高 CPU 线程到处理单元开始。这通常对我来说效果很好，但取决于实际的代码和硬件。运行一些测试并保持灵活性。
您的意思是“每 2 个处理单元 1.5 个 CPU 密集型线程”还是“每个处理单元 1.5 到 2 个 CPU 密集型线程”？
@JonofAllTrades 后一种情况。

标签： c# .net parallel-processing task-parallel-library

【解决方案1】：

不，主要是因为没有任务的定义。任务可以是 CPU 密集型（限制类似于 Cores * 因子）、IO 密集型（限制可能非常低），或者网络密集型受限资源（不喜欢同时处理 1000 个请求）。

因此，作为一名程序员，您应该动用大脑并提出一个概念，然后对其进行验证，然后将其放入您的程序中，具体取决于实际任务是什么以及预见到的瓶颈在哪里。这样的计划可能很复杂——非常复杂——但大多数时候它很简单。

【讨论】：

【解决方案2】：

随着时间的推移，TPL 将自动更改任务的调度方式并添加或删除 ThreadPool 线程。这意味着，如果有足够的时间和类似的工作，默认行为应该改进为最佳选择。

默认情况下，它会使用比内核更多的线程开始，因为许多任务不是“纯 CPU”。鉴于您看到额外的任务导致速度减慢，您可能存在资源争用（通过锁定），或者您的任务受 CPU 限制，并且任务数量多于处理器内核将导致速度减慢。如果这会出现问题，您可以自定义TaskScheduler，以限制一次允许的任务数量，例如LimitedConcurrencyTaskScheduler。这允许您将任务数限制为纯 CPU 场景中的处理器数。

如果您的任务受 IO 等其他因素的约束，那么您可能需要进行分析以确定并发计划任务数和吞吐量之间的最佳平衡，但这将是系统特定的。

【讨论】：

这是一个很好的完全非答案，因为你有点错过了我认为 OP 的观点——他问如何计划这个。
@TomTom 我实际上不同意 - 我只是编辑以添加更多细节，但很大程度上取决于任务正在做什么。鉴于 OP 所描述的行为，很可能是资源争用或 CPU 受限，在这种情况下限制任务数可能是有益的。

【解决方案3】：

假设您的任务是 CPU 密集型任务（即它们不会执行大量 I/O 阻塞，例如读取文件），您可能希望将并行任务的数量限制为您可用的 CPU 内核数量应用。例如，如果您的应用程序在具有四核处理器（即 4 核）的计算机上运行，请将其限制为同时执行 4 个任务。

如果您的任务受到 CPU 以外的其他因素的限制（例如磁盘访问、网络访问等），那么您需要计算出每个任务平均占用的资源份额。如果您知道平均值，那么为了充分利用您的资源，您应该运行的任务数是 100 / average。

【讨论】：