multithreading - 多少线程太多？

Question

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

我的问题是:对于这样的 I/O 线程来说，什么是一个好的截止点？我知道这只是一个粗略的估计，但我们说的是数百个吗？数千？

我该如何弄清楚这个截止值是多少？

<小时/>

编辑:

谢谢大家的回复，看来我必须对其进行测试才能找出我的线程数上限。但问题是:我怎么知道我已经达到了上限？我到底应该测量什么？

Answer 1

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

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

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

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

<小时/>

澄清和阐述:

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

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

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

第一个设置了线程池客户端的最低性能基线(这个数量的线程始终可供使用)。第二个设置对事件线程的资源使用的限制。第三个方法让您在安静的时候回到基线，从而最大限度地减少资源使用。

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

(A) 通常是内存使用情况(堆栈等)，因为不执行任何工作的线程不会使用太多 CPU。 (B) 通常会延迟处理请求，因为您需要等待线程变得可用。

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

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

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

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

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

<小时/>

针对“我到底应该测量什么？”的问题问题:

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

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