[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