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