Why is MySQL nearly twice as fast on Linux?

[Julian Elischer]

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..