Date: Thu, 17 Jun 2004 07:15:25 -0700 From: JG <amd64list@jpgsworld.com> To: freebsd-amd64@freebsd.org Subject: Re: recent -CURRENT changes were very bad for MySQL... Message-ID: <5.2.0.9.2.20040617070109.03265740@mail.ojoink.com> In-Reply-To: <20040616085435.GA46538@dragon.nuxi.com> References: <5.2.0.9.2.20040614175419.0162dd00@127.0.0.1> <5.2.0.9.2.20040614175419.0162dd00@127.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
At 01:54 AM 6/16/2004 -0700, you wrote: >On Mon, Jun 14, 2004 at 06:34:28PM -0700, JG wrote: > > amd64f# super-smack update-select.smack 30 10000 > > > > Query Barrel Report for client smacker > > connect: max=46ms min=2ms avg= 26ms from 30 clients > > Query_type num_queries max_time min_time q_per_s > > select_index 300000 2 0 958.05 > > update_index 300000 2 0 958.05 > > > > In all my previous tests I think that number was at least 2000/qps > > (and that was bad) and as much as 4000/qps. > > > > Whatever was changed recently really killed performance in this area. > > > > This is a SMP kerenel using SCHED_ULE. > >Try commenting out the "options ADAPTIVE_MUTEXES" in GENERIC, and let >this list know if you see any different.. It stopped the erratic numbers and went back to the usual predictably depressing ones when I commented out ADAPTIVE_MUTEXES and ran SCHED_4BSD instead of _ULE (a kernel without ADAPTIVE_MUTEXES w/_ULE failed make ~ some PCI audio stuff, strange, since it didn't fail there before) Anyway Robert Watson (far more qualified at this than me) has been running some MySQL benchmarks and publishing the results in FreeBSD-threads. It's starting to look promising, but in all of his benchmarks that have decent numbers, he specifically has enabled ADAPTIVE_MUTEXES... so maybe this is a problem with ADAPTIVE_MUTEXES that applies specifically to the AMD64 branch? - Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.2.0.9.2.20040617070109.03265740>