[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SLAPD_LISTEN increase

--On Thursday, May 05, 2005 9:59 AM -0700 Doug White <dwhite@gumbysoft.com> wrote:

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

OpenLDAP ITS#3708, patches to implement this welcome. ;)


Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin