Chris Card wrote:
Chris Card wrote:
I am using openldap 2.4.32 on centos 6, on a 24 core box with 132 Gb RAM.
My test directory has ~ 3 million entries, and I loaded it into mdb using
slapadd which took over 2 days (by comparison, the same load into bdb takes 2-3 hours).
This is not normal. With slapadd -q MDB is faster than BDB assuming you're using a decent filesystem and sensible mount options. JFS, EXT2, do better than other filesystems in my tests. Very recent EXT4 may be better than EXT3 as well.
The filesystem is xfs, mounted as a drbd device (although at the moment the other half of the drbd pair is not configured, so it doesn't have to wait for synchronous writes across the network)
Sounds like you're not using slapadd -q. Either that, or your filesystem cache settings are way off.
Your system has enough RAM to hold the entire DB in the filesystem cache. The speed you're reporting indicates that it's not doing so. As another sanity check, look at slapadd -q with the DB on a tmpfs. With correct FS cache settings, the performance delta between tmpfs and a real disk should only be a few percent.
The important sysctl settings on a Linux system are vm.dirty_writeback_centisecs vm.dirty_expire_centisecs vm.dirty_ratio vm.dirty_background_ratio
Note that ext3/ext4 have their own writeback timer, which overrides the sysctl settings, so you need to set theirs at mount time.
The defaults for these settings tend to be low on most Linux systems; their tuning is aimed at machines that are essentially memory-starved so they flush the caches before they get very full. The net effect of this is that even though some userland code performs asynchronous writes, they are effectively synchronous because the OS flushes them out almost immediately. slapadd -q attempts to perform asynchronous writes but it's nullified as a result of these settings.