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 <kris@xxxxxxxxxxx> 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-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Can someone with brains be President?
    ... >> H3rL is H3sm installed into the Linux kernel as a kernel thread. ... >> eforthl is eforth for Linux with 160 syscalls and other tweaks ... >> without a HD and has over 200k free space on the floppy, ash, eforthl, ...
    (alt.politics)
  • Re: mysql scaling questions
    ... same file which is running into exclusive locking in the kernel ... improve caching of the data in userland then performance should improve. ... Isn't this common for software developed for Linux? ... Even if Linux magically has faster syscalls somehow, they are still not zero cost so avoiding huge numbers of unnecessary ...
    (freebsd-performance)
  • Re: mysql scaling questions
    ... same file which is running into exclusive locking in the kernel ... improve caching of the data in userland then performance should improve. ... Isn't this common for software developed for Linux? ... Even if Linux magically has faster syscalls somehow, they are still not zero cost so avoiding huge numbers of unnecessary trips ...
    (freebsd-performance)
  • Re: mysql scaling questions
    ... same file which is running into exclusive locking in the kernel ... improve caching of the data in userland then performance should improve. ... 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". ...
    (freebsd-performance)
  • Re: mysql scaling questions
    ... therefore it has faster syscalls". ... Unixbench is easily patched so the theory I ... So it is using getpid? ... It should be fine on FreeBSD with the previous provisos, but you also need to check Linux behaviour and compare on identical hardware before you can draw conclusions. ...
    (freebsd-performance)