From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 12:27:14 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 66CD716A417; Tue, 1 Jan 2008 12:27:14 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 12EEE13C465; Tue, 1 Jan 2008 12:27:13 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m01CR9E0017608; Tue, 1 Jan 2008 07:27:10 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Tue, 1 Jan 2008 02:28:20 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Gergely CZUCZY In-Reply-To: <20080101122249.GA81405@harmless.hu> Message-ID: <20080101022655.S957@desktop> References: <20071204130810.GA77186@harmless.hu> <47779AA7.2060801@FreeBSD.org> <20071230132451.GA61295@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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kris Kennaway , freebsd-performance@freebsd.org, Ivan Voras 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 12:27:14 -0000 On Tue, 1 Jan 2008, 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. This is true on 32bit x86 and not true on amd64/x86_64. On 32bit x86 platforms our syscalls cost about 750 cycles more due to using int0x80. Various patches have been around for a while to implement sysenter/sysexit support but it's difficult to get compatibility right and probably not worth it now that everyone is moving to 64bit. Cheers, Jeff > > Sincerely, > > Gergely Czuczy > mailto: gergely.czuczy@harmless.hu > > -- > Weenies test. Geniuses solve problems that arise. >