Well, writes are definitely slower than reads. This is especially bad with
writes that sync() frequently, as the default configuration does. (Of
course they're safe, so that makes a sane default.)
With that said, the first big thing you're missing is the -q flag to
slapadd. Note that if the slapadd -q fails, your only recourse will be a
rm. But it looks like your original procedure presumes an rm anyway.
Second, if you've got enough RAM to cache your entire database in-memory,
you should adjust your DB_CONFIG and/or back-bdb directives to do so. This
isn't always possible (depends on entry sizes, number of entries, and
other such variables) but if you can do it, the performance is obviously
fantastic. You can determine the right size using the methods in the
FAQ-O-Matic or, since you're really concerned about load times, one
practical method is to run "slapadd -qv" and look if the times between
entries slow down -- the disk writes, being orders of magnitude slower,
are often visible to the naked eye in my experience. At the end you'll
experience a long flush, but that's good -- it should be gunning your I/O
currently the best way to minimize downtime I found is to replace
"directory" line in slapd.conf, then do slapadd "into" new physical
location, and then just stop slapd, change dirname, change directory
line back, and start again. I'm afraid it's actually not slapd issue,
but just some file-reading/adding -related thing.
Well, yes, an atomic mv is going to be quicker than slapadd. IMO the best
way to minimize downtime is to have lots of replicas, so you can afford to
take as long as you desire with a slapadd in any directory you desire...
I'd be happy to jump to 2.4.7 series, but it still seems
a little bit unstable, segfaults sometimes with some
There are significant performance enhancements in 2.4. Version 2.4.9 seems
to be coming along well and hopefully will fix the seg fault issues you
experience (if you've can, it'd be a great contribution to grab RE24 from
CVS and see if you can reproduce segfaults with those "some searches").