Date: Sat, 24 Feb 2007 22:00:35 -0700 From: "Coleman Kane" <zombyfork@gmail.com> To: "Kris Kennaway" <kris@obsecurity.org> Cc: smp@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: Progress on scaling of FreeBSD on 8 CPU systems Message-ID: <346a80220702242100i7ec22b5h4b25cc7d20d03e98@mail.gmail.com> In-Reply-To: <20070224213111.GB41434@xor.obsecurity.org> References: <20070224213111.GB41434@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/24/07, Kris Kennaway <kris@obsecurity.org> wrote: > > Now that the goals of the SMPng project are complete, for the past > year or more several of us have been working hard on profiling FreeBSD > in various multiprocessor workloads, and looking for performance > bottlenecks to be optimized. > > We have recently made significant progress on optimizing for MySQL > running on an 8-core amd64 system. The graph of results may be found > here: > > http://www.freebsd.org/~kris/scaling/scaling.png > > This shows the graph of MySQL transactions/second performed by a > multi-threaded client workload against a local MySQL database with > varying numbers of client threads, with identically configured FreeBSD > and Linux systems on the same machine. > > The test was run on FreeBSD 7.0, with the latest version of the ULE > 2.0 scheduler, the libthr threading library, and an uncommitted patch > from Jeff Roberson [1] that addresses poor scalability of file > descriptor locking (using a new sleepable mutex primitive); this patch > is responsible for almost all of the performance and scaling > improvements measured. It also includes some other patches (collected > in my kris-contention p4 branch) that have been shown to help > contention in MySQL workloads in the past (including a UNIX domain > socket locking pushdown patch from Robert Watson), but these were > shown to only give small individual contributions, with a cumulative > effect on the order of 5-10%. > > With this configuration we are able to achieve performance that is > consistent with Linux at peak (the graph shows Linux 2% faster, but > this is commensurate with the margin of error coming from variance > between runs, so more data is needed to distinguish them), with 8 > client threads (=1 thread/CPU core), and significantly outperforms > Linux at higher than peak loads, when running on the same hardware. > > Specifically, beyond 8 client threads FreeBSD has only minor > performance degradation (an 8% drop from peak throughput at 8 clients > to 20 clients), but Linux collapses immediately above 8 threads, and > above 14 threads asymptotes to essentially single-threaded levels. At > 20 clients FreeBSD outperforms Linux by a factor of 4. > > We see this result as part of the payoff we are seeing from the hard > work of many developers over the past 7 years. In particular it is a > significant validation of the SMP and locking strategies chosen for > the FreeBSD kernel in the post-FreeBSD 4.x world. > > More configuration details and discussion about the benchmark may be > found here: > > http://people.freebsd.org/~kris/scaling/mysql.html > > Kris > > What does the performance curve look like for the in-CVS 7-CURRENT tree with 4BSD or ULE ? How do those stand up against the Linux SMP scheduler for scalability. It would be nice to see the comparison displayed to see what the performance improvements of the aforementioned patch were realized to. This would likely be a nice graphics for the SMPng project page, BTW... -- Coleman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346a80220702242100i7ec22b5h4b25cc7d20d03e98>