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

RE: LDBM verse BDM

There's one thing to add:

In the thread below there seemed to be a lack of distinction between
back-ldbm configured to use Berkeley DB and back-bdb. The former gives you
little more than back-ldbm with the gdbm (or equivalent) database did
(little fault tolerance, concurrency problems, etc). The latter uses the
transactional support provided by Berkeley DB and has more features than I
can adequately describe here. Suffice it to say that we (Symas) never
recommend the use of back-ldbm to our customers for production environments.

Use the following search terms in Google to get more information on tuning:

OpenLDAP faq Tuning

Also, Quanah Gibson-Mount posted some excellent information that describes
Stanford's experience with back-bdb.

Hope this helps...

Matthew Hardin
Symas Corporation
Packaged, certified, and supported LDAP software:

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org [mailto:owner-openldap-
> software@OpenLDAP.org] On Behalf Of Kent L. Nasveschuk
> Sent: Friday, April 02, 2004 7:07 AM
> To: Frank Swasey
> Subject: Re: LDBM verse BDM
> Hello Frank,
> Just a couple questions regarding, going from ldbm to bdb since bdb
> seems to be the a much better backend for OpenLDAP.
> I've got 4 OpenLDAP servers 2.1.23 (1 master 3 slaves) with ldbm
> backend. If I were to upgrade one at a time any suggestions on how to
> proceed with this? A server that went down in the past, I shutdown
> slapd, copied the db files to the new installations and restarted slapd
> and slurpd. I can't do a direct copy of files with different DB
> backends. Use slapcat on the master then ldapadd on the new machine?
> Thanks
> On Fri, 2004-04-02 at 07:59, Frank Swasey wrote:
> > On Thu, 1 Apr 2004 at 3:55pm, Michael J. Erdely wrote:
> >
> > > Is there a convincing reason to go use a dbm backend instead of ldbm?
> >
> > Yes, there are several.
> >
> > 1) ldbm is not receiving much (if any) development.
> >
> > 2) ldbm has a single lock, so if you can get yourself into a situation
> > where the whole server becomes unresponsive for an extended period of
> > time.  For example, you fire off a search based on a non-indexed
> > attribute that takes a long time.  Someone else asks to modify an
> > attribute.  Their modify is stuck behind your search and any other
> > searches that try to start are now stuck behind their modify.  Several
> > times before I switched to back-bdb, I had to recycle the servers
> > because things were not working.  I haven't had a single one of those
> > deadlock situations since converting to back-bdb.
> >
> > 3) ldbm does not allow slapd to be up and running while performing a
> > slapcat (bdb does).
> >
> > > It seems that the ldbm backend is much easier to setup.
> >
> > That's true.  However, it's kind of like saying an automatic
> > transmission is easier to drive than a manual transmission.  There are
> > trade-offs.  You'll get better gas mileage with a manual transmission
> > once you have learned how to properly operate it.
> >
> > > I'm running OpenLDAP version 2.1.25 on Redhat Enterprise 3 and plan on
> > > supporting about 30k-50k users with about 6-9 indices.
> >
> > I would suggest that you upgrade to 2.1.29 (there were some interesting
> > features in 2.1.25 [as I recall -- but they may only be related to bdb]
> > that have been fixed in 2.1.27 and beyond).
> >
> > > With the ldbm backend, does anyone have any good equations to
> determine the
> > > "cachesize" and "dbcachesize" settings?
> >
> > I do not.
> >
> > > I have only 512 MB of memory but plan on ramping that up to 2 to 4 GB.
> >
> > For the size database you are running 4GB would be plenty for a well
> > tuned back-bdb installation.  I am running several 2.1.27 servers.  I
> > have a couple on RH9 with 2GB of memory and a couple more on RHEL3 with
> > 4GB of memory and they're all running back-bdb.
> >
> > I don't recommend RH9 (unless you also upgrade cyrus-sasl due to bugs in
> > the version RH shipped -- I have to recycle saslauthd once a week).
> --
> Kent L. Nasveschuk <kent@wareham.k12.ma.us>