我正在写一个服务器,当收到请求时,我将每个动作发送到一个单独的线程。我这样做是因为几乎每个请求都要进行数据库查询。我正在使用线程池库来减少线程的构造/破坏。
我的问题是:对于这样的I/O线程,什么是一个好的截断点?我知道这只是一个粗略的估计,但我们说的是几百吗?成千上万的吗?
我怎么才能算出这个界限呢?
编辑:
感谢大家的回复,似乎我只是要测试一下,以找出我的线程数上限。问题是:我怎么知道我已经达到上限了呢?我到底应该测量什么?
我正在写一个服务器,当收到请求时,我将每个动作发送到一个单独的线程。我这样做是因为几乎每个请求都要进行数据库查询。我正在使用线程池库来减少线程的构造/破坏。
我的问题是:对于这样的I/O线程,什么是一个好的截断点?我知道这只是一个粗略的估计,但我们说的是几百吗?成千上万的吗?
我怎么才能算出这个界限呢?
编辑:
感谢大家的回复,似乎我只是要测试一下,以找出我的线程数上限。问题是:我怎么知道我已经达到上限了呢?我到底应该测量什么?
当前回答
“大铁”的答案通常是每个有限的资源一个线程——处理器(CPU限制),臂(I/O限制)等等——但这只有在您能够将工作路由到要访问的资源的正确线程时才有效。
在不可能的情况下,考虑您拥有可替代资源(cpu)和不可替代资源(武器)。对于CPU来说,将每个线程分配给特定的CPU并不重要(尽管这有助于缓存管理),但对于手臂,如果不能将线程分配给手臂,则需要考虑排队理论以及让手臂忙碌的最佳数量。一般来说,我认为如果您不能基于所使用的臂路由请求,那么每个臂有2-3个线程将是正确的。
当传递给线程的工作单元没有执行合理的原子工作单元时,就会出现复杂情况。例如,你可以让线程在一个点访问磁盘,在另一个点在网络上等待。这增加了“裂缝”的数量,其他线程可以进入并做有用的工作,但它也增加了其他线程污染彼此缓存的机会,等等,并使系统陷入困境。
当然,您必须将所有这些与线程的“重量”进行权衡。不幸的是,大多数系统都有非常重量级的线程(而他们所谓的“轻量级线程”通常根本就不是线程),所以最好在低级别上犯错。
我在实践中看到的是,非常细微的差异可能会对最佳线程的数量产生巨大的影响。特别是,缓存问题和锁冲突会极大地限制实际并发的数量。
其他回答
正如帕克斯所说,衡量,而不是猜测。这就是我为DNSwitness所做的事情,结果令人惊讶:理想的线程数比我想象的要高得多,大约15,000个线程才能获得最快的结果。
当然,这取决于很多东西,这就是为什么你必须衡量自己。
在Combien de fils d'exécution ?中的完整测量(仅法语)。
这个问题已经讨论得很透彻了,我还没有机会阅读所有的回答。但是,在查看可以在给定系统中和平共存的并发线程数量的上限时,有几件事需要考虑。
Thread Stack Size : In Linux the default thread stack size is 8MB (you can use ulimit -a to find it out). Max Virtual memory that a given OS variant supports. Linux Kernel 2.4 supports a memory address space of 2 GB. with Kernel 2.6 , I a bit bigger (3GB ) [1] shows the calculations for the max number of threads per given Max VM Supported. For 2.4 it turns out to be about 255 threads. for 2.6 the number is a bit larger. What kindda kernel scheduler you have . Comparing Linux 2.4 kernel scheduler with 2.6 , the later gives you a O(1) scheduling with no dependence upon number of tasks existing in a system while first one is more of a O(n). So also the SMP Capabilities of the kernel schedule also play a good role in max number of sustainable threads in a system.
现在,您可以调整堆栈大小以合并更多线程,但随后必须考虑线程管理的开销(创建/销毁和调度)。 您可以对给定进程和给定线程强制CPU Affinity,将它们绑定到特定的CPU上,以避免CPU之间的线程迁移开销,并避免冷现金问题。
请注意,一个人可以根据自己的意愿创建数千个线程,但是当Linux耗尽VM时,它只是随机地开始杀死进程(因此线程)。这是为了防止实用程序配置文件被刷爆。(效用函数表示给定资源数量的系统范围效用。在这种情况下,CPU周期和内存的资源不变,效用曲线会随着任务数量的增加而变平)。
我相信windows内核调度器也会做一些这样的事情来处理资源的过度使用
[1] http://adywicaksono.wordpress.com/2007/07/10/i-can-not-create-more-than-255-threads-on-linux-what-is-the-solutions/
ryeguy,我目前正在开发一个类似的应用程序,我的线程数设置为15。不幸的是,如果我把它增加到20,它就崩溃了。所以,是的,我认为处理这个问题的最好方法是测量您当前的配置是否允许多于或少于X个线程。
我认为这有点回避你的问题,但是为什么不把它们分成进程呢?我对网络的理解(从以前模糊的日子里,我根本就没有编写网络代码)是每个传入的连接都可以作为一个单独的进程来处理,因为如果有人在您的进程中做了一些讨厌的事情,它不会破坏整个程序。
和CPU内核一样多的线程是我经常听到的。