[Date Prev][Date Next]
Re: bdb backend: memp_trickle
Eric Irrgang wrote:
In typical use there's nothing wrong with BDB 4.3. If you try to run
with transaction logging disabled, then you'll have problems since the
option that worked in 4.2 was removed from 4.3.
On Tue, 15 Feb 2005, Quanah Gibson-Mount wrote:
I'm using OpenLDAP 2.2.23 and Berkeley DB 4.3.27.Okay, I strongly suggest not using BDB 4.3 with OpenLDAP 2.2.
I notice you've made that suggestion before but can't find the original
post. You've said that the logging is broken? Are there fundamental
problems with db4.3 or is it just some bugs that are likely to get fixed
in upcoming releases? Is it a big enough issue that someone should fix
the 2.2.x sources so that the configure script doesn't looke for db4.3
mp_mmapsize is only relevant for databases opened in Read-Only mode.
slapd has to open everything in Read-Write mode, so this option usually
has no effect. It can be useful for slapcat and slapindex, but only if
none of the database was already loaded into the cache. I.e., even if a
database is opened Read-Only, if it already got into the cache (because
of a prior Read-Write usage) then mp_mmapsize is also ignored. With that
said, you can insure that mp_mmapsize takes effect for slapcat/slapindex
by running db_recover beforehand to flush the cache. Obviously slapd
must be shutdown first.
It configures the same as back-bdb. If you have back-bdb configured
already, and you want to try hdb, slapcat, clean up the old db, change
slapd.conf to read "database hdb", slapadd.
"Okay, but what does it DO?" I guess I need to just look through that
code after all. I'm curious as to what it does to reduce writes. I
normally get drastically improved throughput just by using mp_mmapsize
large enough to map all of my database and indexes into process space and
checkpointing infrequently, but sooner or later that data has got to go to
disk, and I'd rather it didn't happen all at once.
That works just fine, as long as you have shared mutexes. By default,
BDB on Linux used assembly-code atomic locks, so that usually works. On
newer Linux systems that have NPTL, BDB prefers to use POSIX mutexes.
That also works fine, unless you try to run with the older LinuxThreads
library, in which case it breaks. I test in both LinuxThreads and NPTL
environments, so I configure BDB not to use POSIX mutexes.
Here's another thought for the BDB brains out there: any reason not to
issue a db_checkpoint from the command line while slapd is running? From
what I can tell, db4 is meant for this type of concurrent activity. I
tried it for grins and it seemed to work fine (afterwards slapd was able
to shut down almost immediately because it had nothing left to flush), but
it creeped me out and I'm reluctant to make a habit of it. :)
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support