mysql scaling questions

Jeff Roberson jroberson at chesapeake.net
Tue Jan 1 04:27:14 PST 2008


On Tue, 1 Jan 2008, Gergely CZUCZY wrote:

> On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
>> Ivan Voras wrote:
>>> Kris Kennaway wrote:
>>>> Gergely CZUCZY wrote:
>>>>>> It looks like myisam is doing huge numbers of concurrent reads of the
>>>>>> same file which is running into exclusive locking in the kernel
>>>>>> (vnode interlock and lockbuilder mtxpool).  Does it not do any
>>>>>> caching of the data in userspace but relies on querying into the
>>>>>> kernel every time? innodb doesn't have this behaviour.
>>>>> Sorry, but was this a rethorical kind of question, or was this
>>>>> addressed to me? :)
>>>>> If the later, then how do I find this out?
>>>> It's a general question.  It looks like myisam either has a design
>>>> deficiency in this regard or it has poor defaults.  If it can be made to
>>>> improve caching of the data in userland then performance should improve.
>>> Isn't this common for software developed for Linux? I mean assuming
>>> syscalls are cheap; for example: gettimeofday(2), settitle(2), etc. I
>>> don't think the applications should be blamed for relying on performance
>>> optimizations not present in FreeBSD. Saying applications must do their
>>> own caching instead of relying on the kernel and need to avoid
>>> concurrent accesses to the same file seems like a doctrine from the dark
>>> ages.
>>
>> Why?  Even if Linux magically has faster syscalls somehow, they are still not zero cost so avoiding huge numbers of unnecessary trips
>> into the kernel is in no sense a "doctrine from the dark ages".  Besides, if my hypothesis about the problem is correct then mysql
>> itself does this with the alternate innodb backend anyway.
> There's this SYSCALL CPU extension with the SYSENTER/SYSEXIT features. IIRC
> Linux takes advantage of this, while FreeBSD doesn't. I might be wrong here,
> of course.

This is true on 32bit x86 and not true on amd64/x86_64.  On 32bit x86 
platforms our syscalls cost about 750 cycles more due to using int0x80. 
Various patches have been around for a while to implement sysenter/sysexit 
support but it's difficult to get compatibility right and probably not 
worth it now that everyone is moving to 64bit.

Cheers,
Jeff

>
> Sincerely,
>
> Gergely Czuczy
> mailto: gergely.czuczy at harmless.hu
>
> -- 
> Weenies test. Geniuses solve problems that arise.
>


More information about the freebsd-performance mailing list