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

Re: slapadd *very* slow: tuning advice?

--On Tuesday, August 21, 2012 4:03 PM +1000 Nick Urbanik <nick.urbanik@optusnet.com.au> wrote:

Dear Folks,

I'm upgrading a cluster of OpenLDAP servers from 2.3.43-25.el5 to
2.4.32 with BDB 4.8.30 on CentOS 5, x86_64, on HP BL460cG6 blades with
two 4-core CPUs, and 12GB RAM.  These are slaves, and have eleven
trees on them.  I have dumped and restored six of the LDAP databases
in reasonable time, but the seventh is taking a long time.  Here are
the sizes of the slapcatted LDIF files:

It's the 2.6G LDIF file that's taking the time to slapadd:
-############          63.34% eta 02h09m elapsed       03h43m30s spd
2.7 k/s 	

As you can see, it has slowed to a crawl.

set_cachesize 0 286162472 0

# egrep 'tool-threads|cachesize' /etc/openldap/slapd.conf
tool-threads 8

cachesize and idlcachesize have no bearing on slapadd. Only toolthreads does.

You do not mention if you are using slapadd -q or not.

Any suggestions on how to optimise this a little more towards slapadd?

If the LDIF file is 2.6GB, I fully assume the BDB database will be significantly larger than 2.6 GB. Probably closer to 6 or 8 GB, depending on your indexing. What you really need to look at from your 2.3 installation is the total size of that database (du -c -h *.bdb).

Right now, you only have a 272MB BDB cache set... which is definitely going to be too small. I would change DB_CONFIG For that database to be something like:

set_cachesize 6 0 0

I would strongly advise examining using a shared memory key for that DB as well.

Finally, look at using MDB, which has zero tuning bits required, and only requires a tool-threads of 2.



Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra ::  the leader in open source messaging and collaboration