Date: Thu, 5 Oct 2006 20:28:39 +0300 From: Sven Petai <hadara@bsd.ee> To: freebsd-performance@freebsd.org Cc: Jerry Bell <jbell@stelesys.com> Subject: Re: Help with improving mysql performance on 6.2PRE Message-ID: <200610052028.41041.hadara@bsd.ee> In-Reply-To: <3731.71.56.92.181.1160009571.squirrel@www.stelesys.com> References: <3731.71.56.92.181.1160009571.squirrel@www.stelesys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 05 October 2006 03:52, Jerry Bell wrote: > I expected the 2950 to be a bit closer to the 1.8Ghz opteron discussed > here: > http://article.gmane.org/gmane.os.freebsd.performance/1137/match=mysql Well he used several patches [1] from the current + ULE scheduler, which seems to give you better results in this particular benchmark, but sometimes seems to have some weird sideefects for realworld usage. Also keep in mind that default select-key smack is just very hard on some specific subsystems. The load it produces is rather unrealistic so better mysql supersmack scores might, but don't necessarily, translate into better real performance. You might get some idea on how different patches and kernelconfigs affect supersmack results on SMP from my latest benchmark run on 8 core machine: http://bsd.ee/~hadara/debug/mysql_sep_2006/stats.html With 8 cores my performance results are of course seriously pessimized by locking contention, I'm not sure how much of a problem it's with 4 cores, but it's very likely that rwatsons uds locking patch [2] that I used will help some in your case too, though I have no idea if it applies to 6.X tree without some hacking. ------- [1] http://lists.freebsd.org/pipermail/freebsd-performance/2006-April/001869.html [2] http://www.watson.org/~robert/freebsd/netperf/20060822-uds-fine-grain.diff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610052028.41041.hadara>