[Date Prev][Date Next] [Chronological] [Thread] [Top]

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/