[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: back-mdb status
Howard Chu wrote:
A couple new results for back-mdb as of today.
first second slapd size
back-hdb, 10K cache 3m6.906s 1m39.835s 7.3GB
back-hdb, 5M cache 3m12.596s 0m10.984s 46.8GB
back-mdb 0m19.420s 0m16.625s 7.0GB
back-mdb 0m15.041s 0m12.356s 7.8GB
Next, the time to execute multiple instances of this search was measured,
using 2, 4, 8, and 16 ldapsearch instances running concurrently.
average result time
2 4 8 16
back-hdb, 5M 0m14.147s 0m17.384s 0m45.665s 17m15.114s
>> back-mdb 0m16.701s 0m16.688s 0m16.621 0m16.955s
> back-mdb 0m12.009s 0m11.978s 0m12.048s 0m12.506s
This result for back-hdb just didn't make any sense. Going back, I discovered
that I'd made a newbie mistake - my slapd was using the libdb-4.7.so that
Debian bundled, instead of the one I had built in /usr/local/lib. Apparently
my LD_LIBRARY_PATH setting that I usually have in my .profile was commented
out when I was working on some other stuff.
While loading a 5 million entry DB for SLAMD testing, I went back and
rechecked these results and got much more reasonable numbers for hdb. Most
likely the main difference is that Debian builds BDB with its default
configuration for mutexes, which is a hybrid that begins with a spinlock and
eventually falls back to a pthread mutex. Spinlocks are nice and fast, but
only for a small number of processors. Since they use atomic instructions that
are meant to lock the memory bus, the coherency traffic they generate is quite
heavy, and it increases geometrically with the number of processors involved.
I always build BDB with an explicit --with-mutex=POSIX/pthreads to avoid the
spinlock code. Linux futexes are decently fast, and scale much better as the
number of processors goes up.
With slapd linked against my build of BDB 4.7, and using the 5 million entry
database instead of the 3.2M entry database I used before, the numbers make
much more sense.
slapadd -q times
back-hdb real 66m09.831s user 115m52.374s sys 5m15.860s
back-mdb real 29m33.212s user 22m21.264s sys 7m11.851s
ldapsearch scanning the entire DB
first second slapd size DB size
back-hdb, 5M 4m15.395s 0m16.204s 26GB 15.6GB
back-mdb 0m14.725s 0m10.807s 10GB 12.8GB
multiple concurrent scans
average result time
2 4 8 16
back-hdb, 5M 0m24.617s 0m32.171s 1m04.817s 3m04.464s
back-mdb 0m10.789s 0m10.842s 0m10.931s 0m12.023s
You can see that up to 4 searches, probably the BDB spinlock would have been
faster. Above that, you need to get rid of the spinlocks. If I had realized I
was using the default BDB build I could of course have configured the BDB
environment with set_tas_spins in the DB_CONFIG file. We used to always set
this to 1, overriding the BDB default of (50 * number of CPUs), before we just
decided to omit them entirely at configure time.
But I think this also illustrates another facet of MDB - reducing config
complexity, so there's a much smaller range of mistakes that can be made.
re: the slapd process size - in my original test I configured a 32GB BDB
environment cache. This particular LDIF only needed an 8GB cache, so that's
the size I used this time around. The 47GB size reported was the Virtual size
of the process, not the Resident size. That was also a mistake, all of the
other numbers are Resident size.
When contemplating the design of MDB I had originally estimated that we could
save somewhere around 2-3x the RAM compared to BDB. With slapd running 2.7x
larger with BDB than MDB on this test DB, that estimate has been proved to be
correct.
The MVCC approach has also proved its value, with no bottlenecks for readers
and response time essentially flat as number of CPUs scales up.
There are still problem areas that need work, but it looks like we're on the
right track, and what started out as possibly-a-good-idea is delivering on the
promise.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/