Date: Tue, 1 Jan 2008 15:34:06 +0200 From: "Vlad GALU" <dudu@dudu.ro> To: freebsd-performance@freebsd.org Subject: Re: mysql scaling questions Message-ID: <ad79ad6b0801010534u3336c2d5l630c1d18a8a493cd@mail.gmail.com> In-Reply-To: <477A32EA.4070500@FreeBSD.org> References: <20071204130810.GA77186@harmless.hu> <47779EBC.5020900@FreeBSD.org> <20071230134354.GA63555@harmless.hu> <4777A65C.8020406@FreeBSD.org> <20071230141118.GA67574@harmless.hu> <4777AB9C.1010003@FreeBSD.org> <flb6bp$8kq$1@ger.gmane.org> <4779BBE8.2050608@FreeBSD.org> <20080101122249.GA81405@harmless.hu> <477A32EA.4070500@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/1/08, Kris Kennaway <kris@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > -- Mahnahmahnah!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ad79ad6b0801010534u3336c2d5l630c1d18a8a493cd>