Re: Long query times: OpenLDAP 1.2.7 + BDB 2.7.7 + Solaris 7

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

For general tuning information, see
  http://www.openldap.org/faq/index.cgi?file=190

At 04:53 PM 9/21/99 -0500, Paul Makepeace wrote:
>The server gets about 10queries/sec and is serving a directory around 60,000
>entries.  The queries typically either return immediately or take a long time,
>e.g. sometimes over a minute to return results as though it was blocking
>somewhere--the bind and result can also come a long time after the initial
>query is issued.

Sounds like reading clients are blocking waiting for writing clients.
Writing is very expense.  By default, slapd syncs the on disk information
upon each update to in memory information.  For an update with numerous
indices to write, this can take significant time.  During this time,
the entry being updated and/or it's parent is locked.

This article provides a nice deployment hint for large directories:
  http://www.openldap.org/lists/openldap-software/9909/msg00090.html

>Virtual Adrian, Sun's free diagnostic tool, reports a lot of
>"Listen queue dropout, speedup accept processing" warnings. I have increased
>the listen queue beyond Sun's original amounts as per
>http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html (which is
>superb) but I'm not sure the issue is really here. The Innosoft directory
>server running on this machine isn't suffering TCP issues.

You are likely spinning your wheels toying with such knobs.

>Has anyone else experienced these kind of problems? Anyone feeling confident
>I'm more than happy to start sending more specific, directed diagnostic &
>debug output (I am collecting -d 65535 info now).

Such logging can REALLY slow down the server.
So can reverse lookups, tcp wrappers, overly complex ACLs, too
many indices, not enough indices, not enough cache, and
BAD CLIENTS.

Yes, bad clients.  Many clients do not reuse LDAP sessions.
Establishing an LDAP session is expensive, a client should reuse
it as much as possible.  (I sure glad sendmail now reuses
LDAP sessions).

>It's pausing for several seconds or more during which time CPU util drops to
>almost nothing on:

Likely waiting for I/O.   See FAQ for suggestions to keep down
unnecessary I/O.

>select activity on 4 descriptors
>accept() failed errno 24 (Too many open files)

64 isn't very many descriptors, nearly half could be used by
slapd for non-networking purposes (databases, logging, etc.).
I'd recommend 1024+ as being much more reasonable.