多少线程太多? [英] How many threads is too many?

问题描述

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

I am writing a server, and I send each action of into a separate thread when the request is received. I do this because almost every request makes a database query. I am using a threadpool library to cut down on construction/destruction of threads.

我的问题是:对于这样的I/O线程，一个好的切入点是什么?我知道这只是一个粗略的估计，但是我们正在讨论数百个吗?几千?

My question is: what is a good cutoff point for I/O threads like these? I know it would just be a rough estimate, but are we talking hundreds? Thousands?

我将如何确定这个临界值?

How would I go about figuring out what this cutoff would be?

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

Thank you all for your responses, it seems like I am just going to have to test it to find out my thread count ceiling. The question is though: how do I know I've hit that ceiling? What exactly should I measure?

推荐答案

有人会说两个线程太多-我在那个阵营还不够:-)

Some people would say that two threads is too many - I'm not quite in that camp :-)

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

Here's my advice: measure, don't guess. One suggestion is to make it configurable and initially set it to 100, then release your software to the wild and monitor what happens.

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

If your thread usage peaks at 3, then 100 is too much. If it remains at 100 for most of the day, bump it up to 200 and see what happens.

您可以实际上让您的代码本身监视使用情况，并在下次启动时调整配置，但这可能会过大.

You could actually have your code itself monitor usage and adjust the configuration for the next time it starts but that's probably overkill.

为了阐明和阐述:

我不主张滚动自己的线程池子系统，请务必使用现有的线程池子系统.但是，由于您询问的是线程的一个很好的临界点，因此我认为您的线程池实现可以限制创建的最大线程数(这是一件好事).

I'm not advocating rolling your own thread pooling subsystem, by all means use the one you have. But, since you were asking about a good cut-off point for threads, I assume your thread pool implementation has the ability to limit the maximum number of threads created (which is a good thing).

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

I've written thread and database connection pooling code and they have the following features (which I believe are essential for performance):

• 活动线程的最小数量.
• 最大线程数.
• 关闭一段时间未使用的线程.

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

The first sets a baseline for minimum performance in terms of the thread pool client (this number of threads is always available for use). The second sets a restriction on resource usage by active threads. The third returns you to the baseline in quiet times so as to minimise resource use.

您需要在没有使用线程(A)的资源使用与没有足够的线程来完成工作(B)的资源使用之间取得平衡.

You need to balance the resource usage of having unused threads (A) against the resource usage of not having enough threads to do the work (B).

(A)通常是内存使用情况(堆栈等)，因为不执行任何操作的线程不会占用大量CPU. (B)通常会延迟请求的处理时间，因为您需要等待线程可用.

(A) is generally memory usage (stacks and so on) since a thread doing no work will not be using much of the CPU. (B) will generally be a delay in the processing of requests as they arrive as you need to wait for a thread to become available.

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

That's why you measure. As you state, the vast majority of your threads will be waiting for a response from the database so they won't be running. There are two factors that affect how many threads you should allow for.

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

The first is the number of DB connections available. This may be a hard limit unless you can increase it at the DBMS - I'm going to assume your DBMS can take an unlimited number of connections in this case (although you should ideally be measuring that as well).

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

Then, the number of threads you should have depend on your historical use. The minimum you should have running is the minimum number that you've ever had running + A%, with an absolute minimum of (for example, and make it configurable just like A) 5.

最大线程数应为您的历史最大值+ B％.

The maximum number of threads should be your historical maximum + B%.

您还应该监视行为更改.如果由于某种原因，您的使用率在相当长的一段时间内达到可用状态的100％(这样会影响客户端的性能)，则应提高允许的最大值，直到再次提高B％.

You should also be monitoring for behaviour changes. If, for some reason, your usage goes to 100% of available for a significant time (so that it would affect the performance of clients), you should bump up the maximum allowed until it's once again B% higher.

针对我应该精确测量什么?"问题:

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

What you should measure specifically is the maximum amount of threads in concurrent use (e.g., waiting on a return from the DB call) under load. Then add a safety factor of 10% for example (emphasised, since other posters seem to take my examples as fixed recommendations).

此外，这应该在生产环境中进行调整.可以事先获得估算值，但是您永远不知道哪种生产方式会影响您的生产(这就是为什么所有这些事情都应该在运行时进行配置的原因).这是为了应对即将来临的客户端呼叫意外加倍的情况.

In addition, this should be done in the production environment for tuning. It's okay to get an estimate beforehand but you never know what production will throw your way (which is why all these things should be configurable at runtime). This is to catch a situation such as unexpected doubling of the client calls coming in.

这篇关于多少线程太多?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！