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"
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. **********************************************************************