[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Speeding up BDB question
First I want to make a correction: The openldap version is 2.4.22, I
had a typo.
> -----Original Message-----
> From: Christian Kratzer [mailto:ck-lists@cksoft.de]
> Sent: Tuesday, April 05, 2011 5:53 AM
> To: Quanah Gibson-Mount
> Cc: Cannady, Mike; openldap-technical@openldap.org
> Subject: Re: Speeding up BDB question
>
> Hi,
>
> On Mon, 4 Apr 2011, Quanah Gibson-Mount wrote:
>
> >
> >
> > --On April 4, 2011 3:12:40 PM -0400 "Cannady, Mike"
> <mike.cannady@htcinc.net>
> > wrote:
> >
> >> I have a situation where I need to delete a major branch of my DIT
and
> >> reload it with a new ldif file on live systems. My current
> >> configuration is a two node multi-master running on Red Hat
Enterprise
> >> 5.4 with openldap 2.22 and BDB 4.8.26.
> >
> > I strongly advise using a later version of OpenLDAP for a variety of
> reasons.
I would like to do that but I have issues with uptime and the two-node
multi-master with readonly replicates off the masters that I'll address
in another post.
> > That aside, why not use a shared memory key for the BDB backing
cache
> instead
> > of putting it on disk?
>
> propably because most people and packagers just default to berkeley db
> file
> based caching and the sysv shared memory caching is largely unknown.
>
> Perhaps this sould be featured more in the documentaion.
I agree. I saw no hint of using sysv shared memory anywhere in the
openldap FAQ. I assume that "DB_SYSTEM_MEM" would have to be in the
DB_CONFIG file and "dbconfig set_flags DB_SYSTEM_MEM" in slapd.conf to
cover a new database. Is this correct?
>
> > Finally, RAM will always be faster than disk. If your database is
> properly
> > configured via the threads, entry cachesize, the idl cachesize, the
> > checkpoint frequency, and the BDB DB_CONFIG configuration for locks,
> lockers,
> > and DB cachesize, then there's probably not much more you can do.
> >
> > Of course, you don't provide any data that lets us know whether or
not
> the
> > settings you showed are valid. I.e., you don't state the number of
DNs
> in
> > the database, or the size of the database, or any of your stats from
the
> BDB
> > database.
>
> I have seen performance get exponentially worse on linux with the
linux
> fsync changes that came somewhere after the 2.6.18 kernels.
Performance
> on linux has never been fully restored with later kernels.
>
> Greetings
> Christian
I used the ram filesystem to see if there was a lot of filesystem
flushing via some kind of sync. The I/Os I saw just didn't seem right
for the amount of changes happening every minute.
As to the database size and such: The ldapadd was adding 51,265 DNs
back into the ldap store. The preceding delete was close to that number
also. The database before any of the operations had 71,886 DNs
>
> --
> Christian Kratzer CK Software GmbH
> Email: ck@cksoft.de Wildberger Weg 24/2
> Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
> Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht
Stuttgart
> Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian
> Kratzer
**********************************************************************
HTC Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.
**********************************************************************