From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 14:19:35 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E45BD16A41B for ; Tue, 1 Jan 2008 14:19:35 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CDF9C13C447; Tue, 1 Jan 2008 14:19:32 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477A4BF1.3050709@FreeBSD.org> Date: Tue, 01 Jan 2008 15:19:29 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Vlad GALU 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> <4779BBE8.2050608@FreeBSD.org> <20080101122249.GA81405@harmless.hu> <477A32EA.4070500@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: mysql scaling questions X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 14:19:36 -0000 Vlad GALU wrote: > On 1/1/08, Kris Kennaway 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. Kris