[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Speeding up BDB question
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Tuesday, April 05, 2011 12:50 PM
> To: Cannady, Mike; Christian Kratzer
> Cc: openldap-technical@openldap.org
> Subject: RE: Speeding up BDB question
>
>
>
> --On April 5, 2011 7:58:19 AM -0400 "Cannady, Mike"
> <mike.cannady@htcinc.net> wrote:
>
>
> > 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?
>
> I'm talking about shared memory keys, which is documented in the
> slapd-bdb(5) and slapd-hdb(5) manual pages.
I was looking at the BDB documentation and missed it in slapd-bdb. I
reconfigured both masters to use shm_key, removed dncachesize and ran
ldapadd. It took only 50 minutes to load 51,265 DNs. That is a better
than the 6-8 hours before. There still seemed to be a lot of small cpu
usage and a lot of I/O waiting.
>
> > 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
>
> Then it is clear your cachesize and idlcachesize settings are all too
> small. I would also note you should never, *EVER*, set the
dncachesize
> unless you are on a terribly memory restricted machine. You should
always
> leave it at the default of infinite.
>
> You still fail to note the size of the BDB database (du -c -h *.bdb)
so
> again it is impossible to say if your DB_CONFIG settings are correct.
>
Sorry about missing the size of the database... Here it is ( 71,914 DNs
):
[root@LDAPdev1 openldap-data]# du -c -h *.bdb
35M cn.bdb
16M dn2id.bdb
3.5M entryCSN.bdb
2.2M entryUUID.bdb
18M givenName.bdb
96M id2entry.bdb
3.2M objectClass.bdb
9.0K ou.bdb
21M sn.bdb
20M uid.bdb
2.0M uniqueIdentifier.bdb
214M total
> --Quanah
>
>
> --
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
I'll bump up the cachesize to 100,000 and idlcachesize to 300,000 and
rerun my tests.
---Thanks for the help!
---Mike Cannady
**********************************************************************
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.
**********************************************************************