multithreading - 多少线程太多了？

Question

我正在编写一个服务器，当收到请求时，我将每个操作发送到一个单独的线程中。我这样做是因为几乎每个请求都会进行数据库查询。我正在使用线程池库来减少线程的构建/销毁。

我的问题是:像这样的 I/O 线程的最佳截止点是多少？我知道这只是一个粗略的估计，但我们是在谈论数百个吗？几千？

我将如何着手弄清楚这个截止点是什么？

---

编辑:

谢谢大家的回复，看来我只需要对其进行测试以找出我的线程数上限。但问题是:我怎么知道我已经达到了上限？我究竟应该测量什么？

Answer 1

有些人会说两个线程太多了——我不完全属于那个阵营:-)

这是我的建议:衡量，不要猜测。一个建议是使其可配置并最初将其设置为 100，然后将您的软件发布到野外并监控发生的情况。

如果您的线程使用量在 3 时达到峰值，那么 100 就太多了。如果一天中的大部分时间都保持在 100，请将其提高到 200，看看会发生什么。

您可以实际上让您的代码本身监控使用情况并在下次启动时调整配置，但这可能有点矫枉过正。

---

澄清和详细说明:

我不是在提倡使用你自己的线程池子系统，一定要使用你已有的。但是，由于您询问的是线程的良好截止点，我假设您的线程池实现能够限制创建的最大线程数(这是一件好事)。

我编写了线程和数据库连接池代码，它们具有以下功能(我认为这些功能对性能至关重要):

• 最小事件线程数。
• 最大线程数。
• 关闭一段时间未使用的线程。

第一个为线程池客户端设置最低性能基准(此线程数始终可用)。第二个限制事件线程的资源使用。第三种方法在安静的时候让你回到基线，以最大限度地减少资源使用。

您需要平衡未使用线程的资源使用 (A) 与没有足够线程完成工作 (B) 的资源使用。

(A) 通常是内存使用情况(堆栈等)，因为不工作的线程不会占用太多 CPU。 (B) 通常会在请求到达时延迟处理请求，因为您需要等待线程可用。

这就是您衡量的原因。正如您所说，绝大多数线程将等待数据库的响应，因此它们不会运行。有两个因素会影响您应允许的线程数。

首先是可用的数据库连接数。这可能是一个硬性限制，除非您可以在 DBMS 上增加它 - 我假设您的 DBMS 在这种情况下可以接受无限数量的连接(尽管理想情况下您也应该测量它)。

那么，你应该拥有的线程数取决于你的历史使用情况。您应该运行的最小值是您运行过的最小值 + A%，绝对最小值(例如，使其像 A 一样可配置)5。

最大线程数应该是您的历史最大值 + B%。

您还应该监控行为变化。如果出于某种原因，您的使用率在很长一段时间内达到 100% 可用(这样会影响客户端的性能)，您应该提高允许的最大值，直到它再次高出 B%。

---

响应“我究竟应该测量什么？”问题:

您应该具体测量的是在负载下并发使用的最大线程数(例如，等待数据库调用的返回)。然后为 example 添加 10% 的安全系数(强调，因为其他张贴者似乎将我的示例作为固定建议)。

此外，这应该在生产环境中进行调优。事先得到一个估计是可以的，但你永远不知道什么产品会影响你(这就是为什么所有这些东西都应该在运行时配置)。这是为了捕获诸如传入的客户端调用意外加倍之类的情况。