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 :)