[Date Prev][Date Next]
Re: slapadd performance
--On Thursday, March 19, 2009 10:11 AM -0700 Howard Chu <firstname.lastname@example.org>
Pete Giesin wrote:
We are using Symas OpenLDAP 184.108.40.206 on a Red Hat EL 5.2 64-bit with
8GB of memory.
My DB_CONFIG settings are:
set_cachesize 3 0 2
The 10 million user load finished in about 18 hours. I believe the
primary issue is the fact that we have a single disk on the system. I
assume that if I were to move the database and log files off to separate
disks I would get much better performance.
With slapadd -q there are no transactions, so there will not be any log
file traffic. It sounds like your DB is very much larger than your
available memory, so you're simply being limited by your disk speed.
Running vmstat while you load would confirm this.
Since you've already loaded your database, you can of course easily gather
the statistics on how big your DB is, and thus what the required DB_CONFIG
settings would be to load it via slapadd in the future.
Cd <data dir>
du -c -h *.bdb
Whatever that total is, is the total size you need DB_CONFIG to be to get
optimal performance. In another note, there is no reason to split the BDB
cache into multiple memory regions (3 0 2) on 64-bit systems, and in fact
past tests I did showed that this decreases performance. I'd suggest (X 0
1) instead (where X is your updated value based on the results of the du -c
-h *.bdb command.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration