Howard Chu wrote:
Howard Chu wrote:
The MVCC approach has also proved its value, with no bottlenecks for readers
and response time essentially flat as number of CPUs scales up.
slamd results have been interesting. The same set of clients that easily push
back-hdb up to 62,000 searches/second at 1485% CPU use are gasping and dying,
pushing back-mdb over 75,000 searches/second at only 1000% CPU use. Once again
I need to bring some more load generator machines online in order to actually
max out slapd.
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.
Here's a report from a slamd run I just completed.
http://highlandsun.com/hyc/slamd-mdb/
The report includes a ModRate job and a SearchRate job; both were run
concurrently. Aside from the fact that the average search rate is over 85,000
searches/second (on a machine that I previously thought was maxed out at
63,000), more interesting is the peak of almost 107,000 searches/second. The
result curve drops, flattens, and then raises again, which shows the influence
of the writers occupying server threads and making then unavailable for
readers, until the writer job finishes.
On this run slapd hit 1300% CPU. Core 0, which was fielding ethernet
interrupts, was at 80% handling soft interrupts. I have no idea whether we can
generate enough load to hit 90% or more there, seems unlikely.
The write rate is pretty slow, as we already knew. I frankly don't see it
improving very much, given the single-writer nature of MDB.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
