[Date Prev][Date Next]
Re: Performance of MDB and BDB Please suggest?
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
The important sysctl settings on a Linux system are
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
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/