Date: Tue, 28 Jun 2005 05:47:51 -0400 From: Jarrod Martin <jmartin37@speakeasy.net> To: Martin Nilsson <martin@gneto.com> Cc: Steve Roome <steve@pepcross.com>, performance@freebsd.org Subject: Re: FreeBSD MySQL still WAY slower than Linux Message-ID: <42C11CC7.3030704@speakeasy.net> In-Reply-To: <42C0E730.5010703@gneto.com> References: <20050623145041.GC64879@bibipentium.lonres.com> <42BD64F1.4080001@roq.com> <20050627134146.GA626@bibipentium.lonres.com> <42C0E730.5010703@gneto.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Martin Nilsson wrote: > Steve Roome wrote: > >> Sorry, good point, here's the my.cnf we're using. Please note however >> that although the configuration may not be optimal, we have been using >> the same config for benchmarking on Linux also. No matter how broken >> this my.cnf is we still shouldn't find MySQL running half the speed on >> an "identical" setups only switching from Linux to FreeBSD. > > > Hi, > Have you tested some more real-world queries on Linux vs. FreeBSD? > The select-key.smack is a very simple test, a very small table (5.3MB > on disk, 90k rows), no joins/sorts and only selects from index. Maybe > the performance difference just affects the > connect/communication/thread syncronistaion and thus this simple test > is a worst case test of performance between Linux & FreeBSD. > > I'll try to set up something here so I can make some tests too... > > How does a P4/Xeon compare to Athlon64/Opteron on these tests (Linux > vs FreeBSD) the long pipeline in the P4 (Prescott/Nocona) is difficult > to optimize for, SMP syncronisation is also much more expensive on > netburst, maybe the are better at doing this in Linux? > > Regards, > Martin > it's better to have several tests that use different functions. for example, testing inserts, then joins and inserts or just joins, selects only, maybe some more complicated queries with math functions involved. perhaps we should come up with a test bed that will specifically test all of these areas on their own and then come up with some real world queries for an all-encompassing overview. and as far as Xeon/P4 goes... it's not very practical. AMDs are far and away the better performing processor right now and the Intel part will only introduce bottlenecks in the testing... don't even get me started on EM64T...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42C11CC7.3030704>