From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 14:21:21 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 8B7FF16A419; Tue, 1 Jan 2008 14:21:21 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id D331513C448; Tue, 1 Jan 2008 14:21:20 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id E968F7C102F; Tue, 1 Jan 2008 15:21:18 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id 81dequ+Sq3rV; Tue, 1 Jan 2008 15:21:18 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 7CBC47C0F83; Tue, 1 Jan 2008 15:21:16 +0100 (CET) Date: Tue, 1 Jan 2008 15:21:16 +0100 From: Gergely CZUCZY To: Kris Kennaway Message-ID: <20080101142116.GA94325@harmless.hu> References: <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> <477A4BF1.3050709@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <477A4BF1.3050709@FreeBSD.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-performance@freebsd.org, Vlad GALU 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:21:21 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 01, 2008 at 03:19:29PM +0100, Kris Kennaway wrote: > 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 ma= de to > >>>>>>improve caching of the data in userland then performance should imp= rove. > >>>>>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 perform= ance > >>>>>optimizations not present in FreeBSD. Saying applications must do th= eir > >>>>>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 s= till not zero cost so avoiding huge numbers of unnecessary=20 > >>>>trips > >>>>into the kernel is in no sense a "doctrine from the dark ages". Besi= des, 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? >=20 > I think a lot of old software (e.g. in ports) still uses it although some= one 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... Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owGFV89vHEkVDrsgoCVW2j8AUeuLbWVmMv4VEgfb63W81rBOYsWTzWZZaVXT/bqn NN1VvVXVHrcPiCMSHBAcWYkDB05ISHDiDjd2b5w48ofwverumUkIwQdrprveq++9 973vvfnV996+9da7X/3pLz+5/ctf//Ybf3znp5PbReW9zvqFtFdK97eGw63+/d2d 7b3+3f72TrpL28Ptvbu0i0c/PLs5/+zEaE/a98d1SfvC07W/U+ZS6QcinkrryB9U Pu3fi7pzD5UrjVNeGb0vlM6VpsW7sZXapWT7pzo2idLZvviiMp6SfmmV9nKSUxQ9 0WJcUU/8WGox3OqJ7eHwnpBeDHf2t+7vb9+/eCRuDwG7Jz6yyomPSGs5l7WYW3ja jw7Fx7lMxNnx+bPlo0M43bqzdWd471WrH83w9f3UEk1cMjA2O1yxOjwjm1Fei5NP n518+mL1zeH/hLm3P9zd37t7/P9gwsfh6ArWHxsr3cvPD99g80ZU4W/kRW7MzIlc zUgUtXKyEPCXGKRcTKuMhK6KCVknTCpio+PKWtRHWJIJPzuIhJ/Sikc4IJGqnMR8 quIpO7OV1uwOdTOCruO8cuqKcHE8ax6zCzEjqylf8bRxpU1CbEWWzwqpk2A0qVSe kBWFvy6NyTcHQjw05ITyQhsP7DhZrziKZTzlixABX5RIL/nSyiGsUsYkJhUHlCv4 MBo8I1sv8L4cXQNS0BWOCK8KOsIpwJzgVnJ63YupRGh+irAnhM/KVHawdHBprK17 4cI5KhnOSdztp8aqWOYCGUkYKEA4boyeMHZxdOlHJokl5ygRgMgo9jeXL0dNnLlE 4nr8UYupmXNeRqgM/IdrTeWPFjYjv85AMtJkgaK7HZl9LUNIwatFrGyUkFOZXrhK KFWxIh3XTWWZAJRJm3AkygcjlM3CLpVV7h1fkvKbGAyf4A55EKHu3ixcqqK0Bml9 QyFzGeJCqCXZ1NhCahTWTU2VJwL2BxF7WFRiFGoVwMWmKFB12AhnUj+XFp5R4NyU SC8/Ple6uj5C8goCQulcVQBF58rVDoXLkQkYxlOS5YNgRdeyKHMIYUaemWLSRNYb 25s94fiBzyl8IR8PxKhzlpgWl56FEGVZ5uAF18J10SBFkxxd1oADbwNZzSLyg4hj 7zyaEperm9YF90cJ5nALI3MfQsw+uHw4EJcyOHnpuqJyoZn89CAiZRcO53pRCKWd hxBwQVZwLLs5tKymhqbyyqik87IiJTKOmcpONN0mlgriiIqWeKCZiT2kH6+sKcJB 0ETaWedRZuS6+j6f1kdCnF6BDipt6gdaZdxhEENmYCqBHBXviudMQWiS0C51KKU7 iLzK85CyG7IGREE+XBvH6+QRMkccirT1wfawhQLMZde4naB02QH7UARtEKh2HOPa fwfJIQqObQ198gFajZvD9TiuAqHUpcEpxzIyQUcHEzQLxmPQ8Rh6Q7FvOqOo3Red wCrvKE+DajVtMEdLN5TLkRgN7eiUbSLjGaGOEFVMmDbFY/Q/rbe2ly8uT47Pz8XJ xTPQHvPbgUBLj3h9+nh8+vQOf/hkNBYpSV+BhQNMj9Ho6UnjsimTlzNAkgnGnUfY Ta8rBIxxAkq0jO3kdsBdqbKp567AdNMZXDK0XuMzDK0Ku0cDe9WamSqL5O5uI3Iu FLtT8QIoluTgmd/j0nfDQFrw3yOxFaslbySxQq8z2DXujVab4tw4FjJgBySWOCSL 24GSteAHXeARdcN9br42veHfcch3j80sFdijwinEWWlMP+eNSdhxUOI85A5Dmfkd ouM5FNy8wnT4G9CAPbVuuEWhVbGH5XyKtaTS6noC/W5mN5XG+k7u5kwj4KEC/GEh 8b7uOgBp/HApe70wclQYygkBACSz87LWYhFQZAvBTNbQrE9S8KahU9g/0AOTWvCx IEwdfpyQflGHQsXgOmMtQpuwNJNbLjAyL7hp0WFzg/cvbRrAO25uC65MuD+eomK6 zTOEu1TJxma7yRS8XhEg4NXjZ6A7CBQ4G+Z5wwswYlmCpL3WLIQWuc0hEKI2FdeU Z9rJk0cXx+PPd3f4NXd9cIQDdonzOHc8uye8osAky9UkDhqMSxYgEVx4viEzGQKV DaaS3IwV7bWM3WRWM5pOpCc8ZS2lVR4e4+OrgXFeg0x33cHnmonVWiw5LCBZ4+c9 FGDeyMEiWpFxhVmx0DNnp49Pn45Oei1fgopKXrAMckAle1oYjscverx/aRHI2IgG FVUeplZoMOPbJsN+0wjxqAUoscuEGw3m6GLab9AgG3D+mOpus5WCyjUrJfQQczeb hhFxEDFslksUth13aGLw2Ld5KRh1KDKnXKpYHF+MMJhGrJWsAuwGyZgpUbKs81YE ZYV4KXbhmgEaeOkqLHaj9SJE5EyUykLlStpOWXFomU8zcYY3PsTlqzTthdE7Wk+a 8YllahaKAFZAtTPTYO91D1bGRmMJWmD9Gwyi6BJUIZ7uvSha/Jy4qeKbOoIo5d7w hhMeD+Lw+H382Cs4A4NpFUX9PpfgOZHm9dpjrxyIM3wJ6QXkq8XFrultid8zoNDP j97+1i3+Vdn9JH33rfjFrd+Nv3n6YPaLr//670c/++o7e3/487e//tf3b335zj+3 /l787b3ff/mZ/c3Od/9xcWiPfvAf =AVu9 -----END PGP SIGNATURE----- --wac7ysb48OaltWcw--