[Date Prev][Date Next]
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 ? :)
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:
Reducing the value may lead to better overall performance.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support