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

Re: thread problem OpenLDAP 2.1.8 + Solaris 8 -- slapd locks or dies



--On Friday, November 15, 2002 3:54 PM +0100 Daniel Tiefnig <openldap@qmail.infonova.at> wrote:


Quanah Gibson-Mount wrote: 
However, 2 things:
1) Resetting our ACL's to just give * by * read, we were only able to
get 36 queries/second max.  We have not yet re-tuned the database (We
are in the process of hiring a consultant for that bit), so there may
be some performance issues there.


Hmm, well, performance is great an a IBM dual p660 (PowerPC RS64-IV)
here with AIX4.3.3, Using OpenLDAP2.1.8 an BerkeleyDB 4.1.24. Got about
700 Requests/second on a 1M entry database.


Daniel,

Assuming that the 26M number means 26 million in db_stat -m, I'd say we have a 26 million entry database.


2) slapd continues to either lock up over time, completely die, or
become so slow in its responses as to be useless, during load testing.


That's a problem I'm working on too at the moment. (Posted 2.1.8 seems
to be rock solid some time ago, spoke to soon.) slapd locks up after a
few 100k requests. After the lock, the DB seems to be corrupt,
db_verify doesn't even return when it's run on one of the files. From
my experience with older versions of OpenLDAP (2.0.X and 1.2.X)
problems on Solaris and AIX are quite the same. (While everything seems
to work great on Linux and *BSD boxes.)

It appears that slapd simply is not freeing up some resources correctly when binds are completed. I ran a test yesterday after putting in an idletimeout of 120, and the above problem disappeared (under Solaris 8).

On Solaris 9, I've found slapd pukes with more than 4 hosts querying at once, but is more responsive than Solaris 8 if you only have a single system querying, and on a 2 CPU 1GHz PIII Linux system, it can't beat 4 queries/second (using GSSAPI anyway, I haven't done an anonymous bind test on it). So at least for this, Solaris has Linux beat. The Linux system also showed signs of slapd holding onto resources... 6 hours after the test had completed, there were approximately 30 slapd processes showing as running. Doing a kill -INT on slapd got rid of most of them, but 3 subprocesses simply would not go away, and the master slapd wouldn't die.

--Quanah

--
Quanah Gibson-Mount
Senior Systems Administrator
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html