Howard Chu wrote:
Howard Chu wrote:
I found the final proof of this conclusion by tweaking slapadd to use DB_PRIVATE when creating the environment. This option just uses malloc for the BDB caches, instead of shared memory. I also ran with tcmalloc. This time the slapadd took only 3:04:21. It would probably be worthwhile to default to DB_PRIVATE when using the -q option. Since slapadd is not extremely heavily threaded, even the default system malloc() will probably work fine. (I'll retest that as well.)
Using glibc 2.7 malloc took 3:16:10, and I didn't bother to rerun the test multiple times. This figure is really not out of line.
With a patched BDB 4.7.13 and a regular shared environment slapadd took 4 hours. (Unpatched 4.7.13 took 8.5 hours.) So it looks like the next BDB release will finally have a decent memory manager. Still not as efficient as malloc, but better than before. Unfortunately it doesn't work with OpenLDAP without additional patching. I'll address that later when BDB 4.7 becomes generally available.
Now if they'd just do something about the (lack of) concurrency in their global lock table... (In a read-only test, slapd with back-hdb is about 3x faster and scales to much heavier client loads with BDB locking disabled. This is also on the Sun T5120.)