Re: performance
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.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/