Steve Langasek wrote: >On Fri, Apr 15, 2005 at 01:30:33PM +0900, Christian Balzer wrote: [backend used] >> See above, LDBM (whatever actual DB that defaults to these days). > >Sorry, I missed that. I would strongly encourage you to switch to BDB, >which is the recommended backend for OpenLDAP 2.2; LDBM was more stable in >2.1 because BDB itself was *un*stable, but in 2.2, BDB is reportedly quite >solid whereas LDBM is less stable than it had been in 2.1. > Seeing that it hardly can get worse (I have been running BDB on a test machine and that worked for the limited exposure it has), I changed the 2 servers over to BDB, something that I would have not done w/o the -q switch in slapadd (all those BDB log files otherwise, argh).
I will monitor this over the weekend and see if the problem persists, goes away or (heavens forbid) mutates. Not matter the outcome of this though, the severity of this bug report remains the same. Right now anybody with a working sarge or woody LDAP installation will find themselves encountering mysterious heisenbugs when upgrading to 2.2.23-1 (at the very least when using LDBM). So unless the underlying problem can be fixed or the update somehow enforces (it didn't even suggest it) BDB usage (always assuming this actually fixes what I'm seeing here) we have a major show stopper. >> I loathe BDB for the times it takes for massive adds/modifies. >> Even with slapadd, which takes about 2 minutes to load the entire DB >> using ldbm as backend, but about 50 minutes with BDB. > >OpenLDAP 2.2 includes a '-q' option to slapadd that makes the load time much >quicker by disabling checks that are unnecessary while loading a fresh db. >This option will be enabled by default on database reloads in the slapd >install scripts. > This sure helps (helped in my case) with a fresh load. I still dread to see BDB performance in case I have something modifying or adding a large number of entries in normal (ldapmodify) operation. It tends to be about 2 times slower than LDBM with that. Regards, Christian Balzer -- Christian Balzer Network/Systems Engineer NOC [EMAIL PROTECTED] Global OnLine Japan/Fusion Network Services http://www.gol.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
