[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: FD_SETSIZE problems on a high-end server

Yes. Our testing showed that 16 threads is a good number for a typical single-processor machine, which is why we lowered the default from 32 down to 16 back in 2.1.x... If you have more processors, you should certainly be able to take advantage of a few more threads, but you need to do your own testing to discover what number suits your situation best. Since there is a considerable memory overhead for each thread, you may find that the number doesn't scale linearly with your number of processors, if your available memory did not scale up accordingly.

Raphaël Ouazana-Sustowski wrote:

I benched my servers under load and I really have best results with a
high number of threads. I see two explanations for that :
- I'm using a bi-p4 processeur, so 4 CPUs are found by Linux.
- I'm using back-meta. In fact I think that if I reduce the number of
threads, the server responds more quickly but often that it can't
respond. Whereas with more threads the responses are slower (because the
system takes more time in context switching), but all ok. Moreother I
didn't need to increase the number of threads on the real OpenLDAP
servers (those with bdb).
Do you think my analysis is correct ? :)

Raphael Ouazana.

Selon "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>:



Increasing the thread parameter past 16 may cause resource
exhaustion and will increase resource contention.  Values from
8-16 are appropriate for most platforms for most deployment
scenarios.   I've added a FAQ answer in this area:




<http://www.openldap.org/faq/index.cgi?file=1129>http://www.openldap.org/faq/index.cgi?file=1129


Reducing the value may lead to better overall performance.


--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support