Re: mysql scaling questions

Gergely CZUCZY wrote:
> On Tue, Jan 01, 2008 at 03:19:29PM +0100, Kris Kennaway
wrote:
>> Vlad GALU wrote:
>>> On 1/1/08, Kris Kennaway <krisfreebsd.org> wrote:
>>>> 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.
>>>> FreeBSD does on amd64.  It still doesn't
make syscalls free, so the
>>>> architectural principle of "cache data
close to where it is needed"
>>>> continues to apply.
>>>>
>>>> Anyway, it remains to be understood whether
linux really does have
>>>> faster syscalls, i.e. to understand exactly
what unixbench is reporting
>>>> when it emits pretty numbers.  For example,
how is it determining
>>>> "syscall overhead"?  Often this
is done by calling a syscall that the
>>>> microbenchmark assumes is doing almost no
work in the kernel.  This is
>>>> often chosen to be getpid() which may well
be NULL on Linux, but
>>>> actually does do work on FreeBSD unless you
remove COMPAT_43BSD from
>>>> your kernel.  Also I believe glibc caches
getpid() in libc (again that
>>>> pesky architectural principle) so you need
to be careful you are
>>>> actually doing the syscalls you think you
are.
>>>>
>>>   BTW, now with COMPAT_43 gone out of GENERIC,
is it necesary to keep
>>> COMPAT_43TTY, even when Linux emulation is not
needed?
>> I think a lot of old software (e.g. in ports) still
uses it although someone is working on converting them to
less archaic APIs.
> Is there some wiki pages or any writings on this issue?
I'm not so
> familiar with this COMPAT_43 obsolated stuff, and I'd
like to
> know what's going on, what's the problem, and so on...

You can just grep for the #ifdef.  In kern_prot.c you see
that in 
getpid() it acquires a mutex in the COMPAT_43 case, which
means that 
getpid is not a "null" syscall since mutex
acquisition has a 
non-negligible cost.  Not relevant for much in the real
world because 
nothing sensible does large numbers of getpid() syscalls,
but it is 
relevant for microbenchmarks, possibly including unixbench.

That's why it's important to dig into the details of what
the benchmark 
is actually doing before you conclude that "the numbers
are higher for 
linux, therefore it has faster syscalls".

Kris

_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"

Re: mysql scaling questions

Thread: Re: mysql scaling questions