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/