Date: Sun, 23 May 2004 12:56:17 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: JG <amd64list@jpgsworld.com> Cc: freebsd-threads@freebsd.org Subject: Re: Why is MySQL nearly twice as fast on Linux? Message-ID: <Pine.BSF.4.21.0405231249110.7925-100000@InterJet.elischer.org> In-Reply-To: <5.2.0.9.2.20040523122839.01597388@mail.ojoink.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 May 2004, JG wrote: > > > > >once again, here's the deal. > > > >i'm willing to PAY someone to own this issue and figure out how to resolve > >it. also give them access to my box to do whatever they feel like (it > >needs to stay AMD64 - but i don't care if you go up to 5.3, down to > >5.2-current, 5.1, whatever) > > > >so i'm supplying resources and incentive. why is nobody stepping up to the > >plate to help figure out where the bottleneck is? it *sounds* like it's > >threading or the scheduler or a combination of both, i don't know. > > > >but i'm pledging at least $250 USD, and someone else will pledge another > >$100 - and that's just two of us. > > > >if someone owns it and can get a fix out in the next week or two (i don't > >care how or where) i could even give a bonus. > > > >once again - resources and incentive. let's figure this out so everyone > >can benefit. i just want to expedite this effort. > > I'm the other $100 sponsor on this offer.... Mike sort of jumped the gun here, > but let me add that we want to see FreeBSD within +/- 10% performance Vs. > "Stock" > Linux results with a comparable or equivalent my.cnf files > > If it's possible, we'll pay to have it happen. There are two things that may help pinpoint the problem firstly, you might try run some work under truss or ktrace and get a feel for the times that various operations take. you might also lile to run a profiled app and a profiled kernel and use gprof and kgmon to get results. There is obviously a bottleneck, but it's very hard to tell what it is.. My guess is that the scheduler(s) are not doing a very good job. and the fact that GIANT is not removed from the kernel yet says that generally syscalls will be a bottleneck. ULE should be able to do a better job at scheduling with multiple CPUs but it is a work in progress. If threads all hit a GIANT based logjam, there is not a lot the scheduler can do about it..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0405231249110.7925-100000>