影响性能之前 Unix 中的线程限制答案

【问题标题】：Thread limit in Unix before affecting performance影响性能之前 Unix 中的线程限制
【发布时间】：2010-02-06 04:41:36
【问题描述】：

我有一些关于线程的问题：

在降低应用程序性能之前，进程允许的最大线程数是多少？
如果有限制，如何更改？
在多线程应用程序中是否有理想的线程数？如果这取决于应用程序在做什么，您能举个例子吗？
影响这些性能/线程限制的因素有哪些？

【问题讨论】：

查看以下问题了解更多信息：stackoverflow.com/questions/1958524/…stackoverflow.com/questions/2118090/…stackoverflow.com/questions/344203/…stackoverflow.com/questions/1399876/…

标签： c++ multithreading unix

【解决方案1】：

这实际上是一组很难回答的问题，没有绝对的答案，但以下应该作为适当的近似值：

它是您的应用程序行为和运行时环境的函数，只能通过实验推断。通常有一个阈值，在该阈值之后，您的性能实际上会随着线程数的增加而下降。
通常，在找到限制之后，您必须弄清楚如何重新设计您的应用程序，以使每线程成本不那么高。（请注意，对于某些领域，您可以通过重新设计算法并减少线程数来获得更好的性能。）
没有一般的“理想”线程数，但您有时可以为特定运行时环境中的应用程序找到最佳线程数。这通常通过实验来完成，并绘制基准结果的图表，同时改变以下内容：
- 线程数。
- 缓冲区大小（如果数据不在 RAM 中）以某个合理的值递增（例如，块大小、数据包大小、缓存大小等）
- 不同的块大小（如果您可以增量处理数据）。
- 用于操作系统或语言运行时的各种调整旋钮。
- 将线程固定到 CPU 以改善局部性。
影响线程限制的因素有很多，但最常见的有：
- 每个线程的内存使用情况（每个线程使用的内存越多，生成的线程就越少）
- 上下文切换成本（您使用的线程越多，切换所花费的 CPU 时间就越多）。
- 锁争用（如果您依赖大量粗粒度锁，增加线程数只会增加争用。）
- 操作系统的线程模型（它如何管理线程？每个线程的成本是多少？）
- 语言运行时的线程模型。（协程、绿色线程、操作系统线程、火花等）
- 硬件。（有多少 CPU/内核？它是超线程吗？操作系统是否适当地对线程进行负载平衡等）
- 等。（还有很多，但以上是最重要的。）

【讨论】：

优秀的答案。我想说锁争用是迄今为止要考虑的最重要的问题。效率，因为它很难隔离，难以调试，并且可以将看起来像可以有效利用多核的程序转换为运行速度比单纯的单处理器实现慢的程序。但请记住：如果调试多线程代码不会杀死你，它会让你变得强大。

【解决方案2】：

问题 1、3 和 4 的答案是“它取决于应用程序”。根据您的线程所做的事情，您可能需要不同的数量来最大限度地提高应用程序的效率。

至于问题 2，几乎可以肯定是有限制的，而且不一定是你可以轻易改变的。每个用户的并发线程数可能受到限制，或者内核中可能存在允许的最大线程数。

【讨论】：

每个用户或#allowedthreads 等精确限制几乎可以肯定是 OS cfg 中可以在编译时更改的幻数。

【解决方案3】：

没有什么固定的：这取决于他们在做什么。有时添加更多线程来执行异步 I/O 可以提高另一个线程的性能，而不会产生不良副作用。
这可能在编译时已修复。
不，这是一个流程架构决定。但是，除了一个或多个执行繁重工作的线程之外，至少还有一个侦听器-调度程序线程表明该数量通常至少应为两个。
几乎可以肯定，您真正掌握正在发生的事情的能力。线程代码很容易以最意想不到的方式阻塞：确保代码没有竞争/死锁是很困难的。研究处理并发的不同方法，例如无共享（参见 Erlang）。

【讨论】：

我从未见过在编译时选择线程限制的 UNIX 实现。 IRIX、Solaris、Linux、Mac OS X 和 FreeBSD 都有线程创建的运行时限制。

【解决方案4】：

只要您使用 CPU 时间的线程数永远不会超过内核数，您将获得最佳性能，但是一旦您必须等待 I/O 就会有未使用的 CPU 周期，因此您可能想要分析您的应用程序，并查看它花费最大 CPU 时间的等待部分，以及等待 RAM、硬盘、网络和其他 IO 的部分，一般来说，如果您正在等待 I/O，您可能还有 1 个线程（前提是您主要受 CPU 限制）。

对于硬性和绝对限制，请查看 limits.h 中的 PTHREAD_THREADS_MAX，这可能就是您要查找的内容。在某些系统上可能是 POSIX_THREAD_MAX。

【讨论】：

【解决方案5】：

任何应用程序的繁忙线程数超过处理器数量都会导致整体速度变慢。有上限，但因系统而异。对于某些人来说，它曾经是 256，您可以重新编译操作系统以使其更高一些。

【讨论】：

不一定，除非您所说的“忙”是指几乎从不等待事情完成。如果一个线程执行大量 IP I/O，而另一个线程执行大量磁盘 I/O（并且没有交换），那么两者都可以全部用完而不会互相踩到。
这是简短的回答。您可以获得更多的响应能力，但无法完成更多的计算，这是大多数人担心多线程的问题。响应性对很多事情来说更重要，但是你会在每个线程上吸收整体系统性能（通常上下文切换并不便宜，这就是实际的完整线程会发生的情况）并且没有理由说例如 12 个 IO 线程.

【解决方案6】：

只要线程被设计为执行单独的任务，那么问题就不大了。但是，当这些线程与资源相交时，问题就开始了，此时应该实现锁定机制。

【讨论】：