--On Thursday, March 19, 2009 10:11 AM -0700 Howard Chu hyc@symas.com wrote:
Pete Giesin wrote:
We are using Symas OpenLDAP 2.4.12.1 on a Red Hat EL 5.2 64-bit with 8GB of memory.
My DB_CONFIG settings are: set_cachesize 3 0 2 set_lk_max_locks 3000 set_lk_max_objects 1500 set_lk_max_lockers 1500 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lg_dir /opt/symas/var/openldap-logs/amwater set_flags DB_LOG_AUTOREMOVE set_tas_spins 1
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.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration