[Date Prev][Date Next]
Re: FD_SETSIZE problems on a high-end server
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.
> At 09:55 AM 10/21/2004, Raphaël Ouazana-Sustowski wrote:
> >Selon Quanah Gibson-Mount <email@example.com>:
> >> Quoting Raphaël Ouazana-Sustowski <firstname.lastname@example.org>:
> >> > If your connections are all active, you may need to increase
> >> threads
> >> > up to about 120.
> >> This is not correct. There is no direct connection between the
> >> number of
> >> threads available to the slapd process and the number of
> >> available. In fact, increasing the number of threads can have
> >> negative impacts on the directory server. The threads paramater
> >> should be
> >> used with caution and a lot of testing to see how your server is
> >> impacted.
> >In fact when I say active I mean not only established connections,
> >working connections, ie connections which load the directory server.
> >this case I think you need at least as much threads as maximum
> >Raphael Ouazana.