[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SLAPD_LISTEN increase
On Thu, 5 May 2005, matthew sporleder wrote:
> I agree that increasing both of those parameters is a good idea, but
> as it says in the tunable docs
> (http://docs.sun.com/app/docs/doc/806-6779/6jfmsfr8a?a=view#chapter4-53
> - I'm running solaris 8) the actual ability of the application to
> utilize the system is based on the listen() queue, so my basic
> question is:
> Why does openldap set this statically to 10? I know my hardware can
> handle a lot more. If there isn't a good reason for it, should I feel
> safe increasing it to better utilize my hardware and service more
> connections? From what some basic benchmarking shows, it is pretty
> safe to increase this number to a large one and rely on the system's
> tunables to control the queues. However, if I wanted to limit the
> application to, say, 65% of the system's available resources, I could
> do so by setting SLAPD_LISTEN =
> (.65*tcp_conn_req_max_q0*tcp_conn_req_max_q/total memory) or something
> like that?
It would be nice to make this a compile option, a la OPENLDAP_FD_SETSIZE,
or a slapd.conf option. As it is now I custom compile slapd on FreeBSD
to set it to '-1' and therefore make it use the system limit in
kern.ipc.somaxconn. 10 is woefully inadequate for any sort of sustained
load, even on fast hardware. (We were doing 200 req/s with TLS and having
problems with bursts getting dropped instead of delayed, which upsets PADL
nss_ldap.
I'll happily test any patches :)
--
Doug White | FreeBSD: The Power to Serve
dwhite@gumbysoft.com | www.FreeBSD.org