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

Re: alock File Keeps LDAP (slapd) from Starting Up





--On Thursday, May 25, 2006 4:32 PM -0700 Todd Lyons <tlyons@ivenue.com> wrote:

On Thu, May 25, 2006 at 01:56:22PM -0700, Todd Lyons wrote:

BDB 4.3 is a known problem release.  The suggested BDB release is
4.2.52+patches, and possible BDB 4.4.20+patches.  But not BDB
4.3.anything.
Ah, that's good to know.  I upgraded an old 2.1.30 production server to
2.3.21 with bdb 4.3 and the load went through the roof, searches were
blindingly slow, etc.  I'm rolling back to 2.2.30 right now with db 4.2.
We'll see if that fixes my speed problem.

Followup: No, it didn't fix the speed problem. When using the ldbm backend, the machine sits at load around 0.1 and 2% or 3% cpu usage. I switch to bdb backend and my load jumps to 14 or so, searches take seconds to complete (of course slows down as the load gets higher). At that point, the acceptance of new incoming connects gets degraded enough that it drops out of the load balancer until OpenLDAP catches up on things. In short, I wasn't able to get it to work. I had to go back to ldbm. I'll keep hacking away at it.

Well, since you are using a version of BDB that is recommended you not use, all bets are off. On my AMD boxes, I get some 13,000 searches/second using BDB as the backend (bdb 4.2.52+patches) on a 1 million entry database.


As for your conf file, I don't see any idlcachesize setting.


As for DB_CONFIG, a general rule to start with is:

Cache size should be size of id2entry.bdb + 10%, which in your case means your DB_CONFIG file is not set up correctly for the cachesize.

52428800 (your cache size setting) vs 64372736 (size of your id2entry.bdb file)



--Quanah

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