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

Re: back-mdb status

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

Here's a report from a slamd run I just completed.


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/