Comment 15 for bug 16317

Message-Id: <email address hidden>
Date: Fri, 15 Apr 2005 14:57:48 +0900
From: Christian Balzer <email address hidden>
To: Steve Langasek <email address hidden>, <email address hidden>
Subject: Re: Bug#304735: slapd 2.2.23 database corruption

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 address hidden> Global OnLine Japan/Fusion Network Services
http://www.gol.com/