[Date Prev][Date Next]
Re: thread problem OpenLDAP 2.1.8 + Solaris 8 -- slapd locks or dies
--On Friday, November 15, 2002 3:54 PM +0100 Daniel Tiefnig
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.
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.
Senior Systems Administrator
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html