Dusty Doris wrote:
The problems I had with BDB 4.3 (21 & 27) were related to data
loading via slapadd (and the use of IN-MEMORY logs). The "-q"
function in 2.3 removes the necessity of the IN-MEMORY logs. The
other issues seen in 21 & 27 were reported by other people, and may
well have been resolved in 4.3.28.
I did run into some snags testing openldap 2.3.7 w/ syncprov.c from HEAD
and BDB 4.2 or 4.3 today when using hdb as the backend.
When I initially start up the slapd, it starts no problem. But then
something happens during the initial search that takes some time. If
I do
an initial single search and wait for the response, it takes about 10
seconds and then each search after that point is immediate.
The problem is if I start a bunch of searches when the initial load up
happens. In my case the searches are generated from a radius server
and they are aborted after a few seconds. The slapd process slowly
creeps
up over 100% when running top and I get a bunch of these in the logs
Funny you should mention this. Quanah and I just spent the last couple
days profiling / benchmarking back-hdb. While hdb's write performance is
better than bdb's, its search performance was terrible. Profiling
identified a couple of bottlenecks that I have now rewritten, and
back-hdb search performance is now as fast as or faster than back-bdb
(in CVS HEAD - over a 4x speedup vs 2.3.7). We still have more
benchmarks to run, but you might want to test the current CVS HEAD and
see how it behaves with your data.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
