mysql scaling questions

[Vlad GALU]

On 1/1/08, Kris Kennaway <kris at freebsd.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?

> Kris
>
> _______________________________________________
> freebsd-performance at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to "freebsd-performance-unsubscribe at freebsd.org"
>


-- 
Mahnahmahnah!