From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 03:52:16 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 CBA9A16A41B; Tue, 1 Jan 2008 03:52:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 62EDB13C457; Tue, 1 Jan 2008 03:52:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m011rorQ007897; Tue, 1 Jan 2008 12:53:50 +1100 Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m011riML023354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 12:53:48 +1100 Date: Tue, 1 Jan 2008 12:53:44 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Ivan Voras In-Reply-To: Message-ID: <20080101122038.S9795@delplex.bde.org> References: <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 03:52:17 -0000 On Mon, 31 Dec 2007, Ivan Voras wrote: > Kris Kennaway wrote: >> 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 > ... > Does anyone have a theory why syscalls are so expensive in FreeBSD? Here FreeBSD has more layers, with less optimization in each layer. Normally this doesn't matter, since everyone knows that syscalls are expensive and avoids them :-). > are the results of unixbench 4.1 on two machines. First is the machine > running FreeBSD HEAD (debugging disabled) on a dual-core Athlon 64 (i386 > mode), 2 GHz: > > INDEX VALUES > TEST BASELINE RESULT INDEX > > Dhrystone 2 using register variables 116700.0 6467105.1 554.2 > Double-Precision Whetstone 55.0 1633.7 297.0 > Execl Throughput 43.0 2030.9 472.3 > File Copy 1024 bufsize 2000 maxblocks 3960.0 63783.0 161.1 > File Copy 256 bufsize 500 maxblocks 1655.0 57489.0 347.4 > File Copy 4096 bufsize 8000 maxblocks 5800.0 53476.0 92.2 > Pipe Throughput 12440.0 930715.9 748.2 > Pipe-based Context Switching 4000.0 204248.8 510.6 > Process Creation 126.0 5373.3 426.5 > Shell Scripts (8 concurrent) 6.0 563.7 939.5 > System Call Overhead 15000.0 720641.0 480.4 > ========= > FINAL SCORE 387.4 > > The second result is from a machine running Linux 2.6.22, dual-core Core > 2 Duo, 1.7 GHz, T2250, i386 mode (i.e. slower than the first machine): Isn't Core2 significantly faster than A64 at the same clock speed? Its larger L2 cache is likely to be especially helpful in benchmarks. > INDEX VALUES > TEST BASELINE RESULT INDEX > > Dhrystone 2 using register variables 116700.0 5576224.9 477.8 > Double-Precision Whetstone 55.0 1521.6 276.7 > Execl Throughput 43.0 2734.1 635.8 > File Copy 1024 bufsize 2000 maxblocks 3960.0 316794.0 800.0 > File Copy 256 bufsize 500 maxblocks 1655.0 97964.0 591.9 > File Copy 4096 bufsize 8000 maxblocks 5800.0 665840.0 1148.0 > Pipe Throughput 12440.0 679339.1 546.1 No Pipe-based Context Switching? That should be included in benchmarks to show FreeBSD slowness :-), since it is affected by both slow syscalls and slow context switches. > Process Creation 126.0 11562.9 917.7 > Shell Scripts (8 concurrent) 6.0 316.0 526.7 > System Call Overhead 15000.0 1134690.6 756.5 > ========= > FINAL SCORE 625.2 > This is almost comparing apples to oranges, but the difference in > syscall-intensive operations (execl, syscall, process creation) seems > anomalous, since everything should go against the second machine. Um, execl and process creation are not syscall-intensive. They take about 1 syscall each. Linux wins this benchmark by a lot mainly because too much weight is given to the file copy benchmarks, using a number of files that just happens to cause more physical writes under FreeBSD than under Linux, mainly due to FreeBSD's policy of not letting the buffer cache/VMIO fill up with dirty buffers/pages. FreeBSD does much better with more files. FreeBSD does worse than I like for cases where physical writes aren't made by either OS. The source of this slowness seems to be the same as for syscalls but more so (vfs intentionally has lots of layers in FreeBSD). Bruce From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 10:51:54 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 B59F816A418; Tue, 1 Jan 2008 10:51:54 +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 7832713C458; Tue, 1 Jan 2008 10:51:44 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4779BBE8.2050608@FreeBSD.org> Date: Tue, 01 Jan 2008 05:04:56 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras References: <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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 10:51:54 -0000 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. Kris From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 12:22:54 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 8F27916A420; Tue, 1 Jan 2008 12:22:54 +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 3E4EE13C448; Tue, 1 Jan 2008 12:22:54 +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 EDC387BFF0E; Tue, 1 Jan 2008 13:22:51 +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 V+9DhmSe3NEp; Tue, 1 Jan 2008 13:22:51 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 818DE7BFF1E; Tue, 1 Jan 2008 13:22:49 +0100 (CET) Date: Tue, 1 Jan 2008 13:22:49 +0100 From: Gergely CZUCZY To: Kris Kennaway Message-ID: <20080101122249.GA81405@harmless.hu> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <4779BBE8.2050608@FreeBSD.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: 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:22:54 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > Why? Even if Linux magically has faster syscalls somehow, they are still= not zero cost so avoiding huge numbers of unnecessary trips=20 > into the kernel is in no sense a "doctrine from the dark ages". Besides,= if my hypothesis about the problem is correct then mysql=20 > 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. Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owF9Vs+LHEUUXhMM0uAhePAmj4gkITOT2ZCNuxOya7K7hjHrD7IbYzYI1nS/ni6n uqpTVT2zveJBvCiIiCAIHiJ48aLxoFcPgldP/gn+IX5VPbObQPQ2XVXvve+973vv zVfPn1w6cfqvX369f+GLr7975qfnXh5dKGvv9bhbCjuVurvc7y93V5cv91e6V7or WT66siL48traWn/11bWbh/1vN432rH13r6l4QJ4P/MVKCamvUloI69hfq33eXU0W 77akq4yTXho9IKmV1Hx0t2eFdjnb7rZOTSb1eEAPauM561ZWai9GipPkbU17NXfo DaGpv9yhS/3+KglP/ZVB//Jg5cr1N+lCH7A7dMtKR7dYazETDc0sPA2SdRpOYfmu scIdn63/x9v19Ztsx6wa2ty/s7l/7/Gb9fWhJ2XMxJGSE6aykU6UBD+ZAXYq6jGT rssRW0cmp9TotLYWiZJlkcUzX/DcF0yZcqmYZoVMi+DG1loHR0jdEB+kqnZyygiZ TtrjYE4TtprV3Mu5qTYZBwu24R0JnUWDUS1VxpZKf1AZo873iLYMO5KetPFAjJfN 3Ekq0iIEaPFRJrwIwWqHRCqRMo3qkIKSsDcaFLFtjnAeZ9QCI57imrwseQMvAG+E aOz0WU+FQDq+QKojxm9pattrjXeNtU0nBpqBp/hGIKYvjJWpUIQKZAEggrugpQ4Z e/S09SGyzLJznBFgheiD8+3FsM1LCRSpE35qKsws1GAIBuA3hjO134jvh/5sCD5m zRaRFxFRwafyzxIeLXILRhk7OdbRTca5TCXrtGmZCwTzWNgsIJc+GoAaC5tc1Mq7 ECAPNyn0OoJ/AWa9ic5kWVmD4v0PVUrETJBcxTY3thQa1LnC1CqjuX2s9jByEQGl pizBKF6TM7mfCQufIFCZCmUMxztS1wcbKFTJQCWcq0vED25c40CMQtYwSgsW1dVo wQeirBRmw5h9UIHJM9Gcu3S+Qy4ceMXxg33ao2FwlJk5Hj2JSYmqUuA81Nwt8KMc I4WOaUFBi1GA5olcgy9TIaQ8nBsHpVfQRGhBVOl1y3xjd6tHuyKaPxGorF1sCyCQ Nrqa6aNyS+08WjiU/bHYx90Y205zKz0xNTILHh4bACJNgzQdtR1Dx93vmMu5oCAf k3pMPlxZU84ZtpPgS4zZgb1rl/r4uls0G0TbU3At85YiqGUcGgWTKwgrFwAMUhcc OVMyNB/V30TGoGmlriWxRodsDbSAArg5/KfNM0wnDlmI0N5WVq4Fs5gCi1JAVqi1 NshMu5DUmadnRSGlMxD9DfQM+qYDMMimRAJNZfDKhRkwQltGE+gX6yCO2xTDglPf ir1s3AM1R+IdqzxOm1beM7RmKymFamj0/2IijUQ6YXCGIYj530v20MJ8dm62e293 8/rODm2+cwdqxqZyUMixM1xvv7W3ffti+PHecI9yFr6GzKDn4e3NpOXDiwlgiAzL xyPTtmOl64RxD9rnWlyMxl7oMDkufFA6dk4oPxB1krhHauzVXpLsSqg86K+TJEdr 6rBOD5ukFFJ5E3ouHvfSePwaNnKpQFmvqJOk2w1lususwyD3mGo9uomPOujSGTU9 KnKoAzaswI5E3M82Tj67FFb/4n/D6RMfrS99/4j/+Xv/45d+PtX8+Wj5zKdf/vHi 2nDp4daHP24NPv/hhf3pN6cefvL7Kx/svP/bvw== =jKfX -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- 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. > From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 12:32:52 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 CEFF716A418; Tue, 1 Jan 2008 12:32:52 +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 ADFA813C442; Tue, 1 Jan 2008 12:32:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477A32EA.4070500@FreeBSD.org> Date: Tue, 01 Jan 2008 13:32:42 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gergely CZUCZY 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> In-Reply-To: <20080101122249.GA81405@harmless.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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:32:52 -0000 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. Kris From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 14:03: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 A6EF316A417 for ; Tue, 1 Jan 2008 14:03:21 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 29CD213C448 for ; Tue, 1 Jan 2008 14:03:20 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fg-out-1718.google.com with SMTP id 16so3614920fgg.35 for ; Tue, 01 Jan 2008 06:03:20 -0800 (PST) Received: by 10.82.124.10 with SMTP id w10mr23588307buc.33.1199194446076; Tue, 01 Jan 2008 05:34:06 -0800 (PST) Received: by 10.82.148.1 with HTTP; Tue, 1 Jan 2008 05:34:06 -0800 (PST) Message-ID: Date: Tue, 1 Jan 2008 15:34:06 +0200 From: "Vlad GALU" To: freebsd-performance@freebsd.org In-Reply-To: <477A32EA.4070500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> 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:03:21 -0000 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? > 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! 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 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-- From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 14:29:03 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 7686916A419 for ; Tue, 1 Jan 2008 14:29:03 +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 60A3013C467; Tue, 1 Jan 2008 14:28:59 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477A4E28.3010003@FreeBSD.org> Date: Tue, 01 Jan 2008 15:28:56 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gergely CZUCZY 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> <20080101142116.GA94325@harmless.hu> In-Reply-To: <20080101142116.GA94325@harmless.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:29:03 -0000 Gergely CZUCZY wrote: > 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 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. > 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... You can just grep for the #ifdef. In kern_prot.c you see that in getpid() it acquires a mutex in the COMPAT_43 case, which means that getpid is not a "null" syscall since mutex acquisition has a non-negligible cost. Not relevant for much in the real world because nothing sensible does large numbers of getpid() syscalls, but it is relevant for microbenchmarks, possibly including unixbench. That's why it's important to dig into the details of what the benchmark is actually doing before you conclude that "the numbers are higher for linux, therefore it has faster syscalls". Kris From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 16:52:46 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 C369916A419 for ; Tue, 1 Jan 2008 16:52:46 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 79B1D13C457 for ; Tue, 1 Jan 2008 16:52:46 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5810666B50C; Tue, 1 Jan 2008 17:33:36 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztW0hoxvs6Gv; Tue, 1 Jan 2008 17:33:26 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 30B8766B4B3; Tue, 1 Jan 2008 17:33:26 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id m01GXP23098499; Tue, 1 Jan 2008 17:33:25 +0100 (CET) (envelope-from rdivacky) Date: Tue, 1 Jan 2008 17:33:25 +0100 From: Roman Divacky To: Vlad GALU Message-ID: <20080101163325.GA98449@freebsd.org> References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i 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 16:52:46 -0000 > BTW, now with COMPAT_43 gone out of GENERIC, is it necesary to keep > COMPAT_43TTY, even when Linux emulation is not needed? COMPAT_43TTY just adds a bunch of sysctls, it does not slow down anything. COMPAT_43 did slow down things (the getpid for example) and it was removed. I dont see any problem :) From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 17:01:16 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 967F316A41B; Tue, 1 Jan 2008 17:01:16 +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 8ED9E13C461; Tue, 1 Jan 2008 17:01:15 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477A71D9.1050508@FreeBSD.org> Date: Tue, 01 Jan 2008 18:01:13 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Roman Divacky References: <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> <20080101163325.GA98449@freebsd.org> In-Reply-To: <20080101163325.GA98449@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 17:01:16 -0000 Roman Divacky wrote: >> BTW, now with COMPAT_43 gone out of GENERIC, is it necesary to keep >> COMPAT_43TTY, even when Linux emulation is not needed? > > COMPAT_43TTY just adds a bunch of sysctls, it does not slow down anything. > COMPAT_43 did slow down things (the getpid for example) and it was removed. > I dont see any problem :) It is likely to remain in people's custom kernels, possibly including the one used by Ivan. Anyway, this is all speculation until someone studies the claims in more detail. Kris From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 20:15:11 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 21C9116A421 for ; Tue, 1 Jan 2008 20:15:11 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C6BFE13C4D1 for ; Tue, 1 Jan 2008 20:15:10 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J9nVm-0003Pi-9x for freebsd-performance@freebsd.org; Tue, 01 Jan 2008 20:14:54 +0000 Received: from 78-1-101-174.adsl.net.t-com.hr ([78.1.101.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2008 20:14:54 +0000 Received: from ivoras by 78-1-101-174.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2008 20:14:54 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Tue, 01 Jan 2008 21:14:41 +0100 Lines: 33 Message-ID: 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> <20080101142116.GA94325@harmless.hu> <477A4E28.3010003@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE53DFCD3C388AE49FF39AA6C" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-101-174.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <477A4E28.3010003@FreeBSD.org> X-Enigmail-Version: 0.95.5 Sender: news 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 20:15:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE53DFCD3C388AE49FF39AA6C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > That's why it's important to dig into the details of what the benchmark= > is actually doing before you conclude that "the numbers are higher for > linux, therefore it has faster syscalls". Can you propose a simpler syscall on the GENERIC kernel that could be used instead of getpid()? Unixbench is easily patched so the theory I put out can be easily checked. --------------enigE53DFCD3C388AE49FF39AA6C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHep8xldnAQVacBcgRAutQAJ0U0wGv/aEVuxXg3/2WK82vl6FXMACg3QY0 /VPJRSS+RO1wu3QEZcxpfy8= =MelS -----END PGP SIGNATURE----- --------------enigE53DFCD3C388AE49FF39AA6C-- From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 20:20:23 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 37B7E16A417 for ; Tue, 1 Jan 2008 20:20:23 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D3C2C13C45A for ; Tue, 1 Jan 2008 20:20:22 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1J9nal-0004Vu-86 for freebsd-performance@freebsd.org; Tue, 01 Jan 2008 20:20:03 +0000 Received: from 78-1-101-174.adsl.net.t-com.hr ([78.1.101.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2008 20:20:03 +0000 Received: from ivoras by 78-1-101-174.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2008 20:20:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Tue, 01 Jan 2008 21:15:16 +0100 Lines: 29 Message-ID: References: <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> <20080101163325.GA98449@freebsd.org> <477A71D9.1050508@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9B9B1F796C82A383CA2F8373" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-101-174.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <477A71D9.1050508@FreeBSD.org> X-Enigmail-Version: 0.95.5 Sender: news 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 20:20:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9B9B1F796C82A383CA2F8373 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > It is likely to remain in people's custom kernels, possibly including > the one used by Ivan. Anyway, this is all speculation until someone > studies the claims in more detail. I'm using GENERIC minus debugging options. --------------enig9B9B1F796C82A383CA2F8373 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHep9UldnAQVacBcgRAijkAJ0ajSaLveToHufUlcRgpJdsSeoqnACbBIE5 EtNg+Y2uWRxPmGknYv7Y1CQ= =1JNI -----END PGP SIGNATURE----- --------------enig9B9B1F796C82A383CA2F8373-- From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 21:11:50 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 230C716A418; Tue, 1 Jan 2008 21:11:50 +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 95A5213C43E; Tue, 1 Jan 2008 21:11:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477AAC90.4050305@FreeBSD.org> Date: Tue, 01 Jan 2008 22:11:44 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Ivan Voras 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> <20080101142116.GA94325@harmless.hu> <477A4E28.3010003@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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 21:11:50 -0000 Ivan Voras wrote: > Kris Kennaway wrote: > >> That's why it's important to dig into the details of what the benchmark >> is actually doing before you conclude that "the numbers are higher for >> linux, therefore it has faster syscalls". > > Can you propose a simpler syscall on the GENERIC kernel that could be > used instead of getpid()? Unixbench is easily patched so the theory I > put out can be easily checked. > > So it is using getpid? It should be fine on FreeBSD with the previous provisos, but you also need to check Linux behaviour and compare on identical hardware before you can draw conclusions. Kris From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 22:27:39 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 3168316A46C; Tue, 1 Jan 2008 22:27:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id BB05613C45D; Tue, 1 Jan 2008 22:27:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m01MRKXM006453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 09:27:26 +1100 Date: Wed, 2 Jan 2008 09:27:20 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jeff Roberson In-Reply-To: <20080101022655.S957@desktop> Message-ID: <20080102084139.X12725@delplex.bde.org> 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> <20080101022655.S957@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Gergely CZUCZY , 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 22:27:39 -0000 On Tue, 1 Jan 2008, Jeff Roberson wrote: > On Tue, 1 Jan 2008, Gergely CZUCZY wrote: >> 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. No, syscalls on i386 UP take about 65 cyles _less_ than on amd64, due mainly to 64-bit code and data being larger. A syscall takes about 385 cycles on an A64 running i386 UP (0.17us @ 2.205GHz), so it can't possibly take 750 cycles more than on the same A64 running amd64 UP (0.20us @ 2.205GHz). I think SYSENTER/SYSEXIT saves more like 7.5 or 75 cycles and thus compensates for some of the 64-bit overhead, else amd64 would be even slower. I don't have documents or measurements for current int0x80 or SYS* times -- on i486, int0x80 takes about 80 cycles and iret takes about the same, so the total overhead from the bad hardware interface is about half of the total syscall overerhead. The times 0.17us and 0.20us are from lmbench2 doing a COMPAT_43 getppid(). As is well known, getppid() is a better benchmark than getpid() since it is much harder for libraries to cache (since the parent may change to init at any time). In FreeBSD, it always does proc locking, while getpid() only does proc locking if COMPAT_43. But the overhead for uncontested locking on UP is in the noise -- it is about 5-10 cycles on this hardware. lmbench2 is not up to date enough enough to report things with nanoseconds resolution. I have more accurate measurements for clock_gettime(). After some optimizations, clock_gettime() timing itself takes an average of 233ns in my version of 5.2 and 250-260ns in -current, both on i386 UP @2.205GHz. Linux-2.6.10 i386 UP takes 0.13us for getpid() on slightly different hardware (AXP 2.223GHz) where FreeBSD i386 UP takes slightly longer than on the A64 (0.17-0.18us). Not a big difference. The difference is more interesting for the even-more-bogus "null I/O" micro-benchmark. This writes 1 byte to /dev/null. Linux used to be 4-5 times faster on this (on the AXP, in 0.16us in Linux-2.3.99 vs 0.90us in FreeBSD-~5.2), but Linux has been speeded down (0.19us in Linux-2.6.10) and FreeBSD has been speeded up (0.33us on the A64 in -current). I consider the speedups bogus since they consist of combining/avoiding vfs layers for devices only. The usual case of (cached) file i/o remains unnecessarily slow. (For most devices, and for uncached file i/o, the hardware part is necessarily slow, so optimization of the software hardly matters.) Bruce From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 22:44:51 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 C59E316A418 for ; Tue, 1 Jan 2008 22:44:51 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4666513C455 for ; Tue, 1 Jan 2008 22:44:51 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J9pqp-0002cv-4e for freebsd-performance@freebsd.org; Tue, 01 Jan 2008 22:44:47 +0000 Received: from 78-1-101-174.adsl.net.t-com.hr ([78.1.101.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2008 22:44:47 +0000 Received: from ivoras by 78-1-101-174.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2008 22:44:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Tue, 01 Jan 2008 23:44:18 +0100 Lines: 69 Message-ID: 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> <20080101142116.GA94325@harmless.hu> <477A4E28.3010003@FreeBSD.org> <477AAC90.4050305@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6CEE54D3F0BA2EC9C26BE77C" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-101-174.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <477AAC90.4050305@FreeBSD.org> X-Enigmail-Version: 0.95.5 Sender: news 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 22:44:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6CEE54D3F0BA2EC9C26BE77C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > So it is using getpid? It should be fine on FreeBSD with the previous > provisos, but you also need to check Linux behaviour and compare on > identical hardware before you can draw conclusions. Here's the source of unixbench syscall benchmark: unsigned long iter; void report() { fprintf(stderr,"%ld loops\n", iter); exit(0); } int main(argc, argv) int argc; char *argv[]; { int duration; if (argc !=3D 2) { printf("Usage: %s duration\n", argv[0]); exit(1); } duration =3D atoi(argv[1]); iter =3D 0; wake_me(duration, report); while (1) { close(dup(0)); getpid(); getuid(); umask(022); iter++; } /* NOTREACHED */ } As I count it, getpid() is one of 5 syscalls made. Of these, getpid() and getuid() might be cached on Linux in some way, which actually could, with the difference in CPU speed, cause the difference. I can't check it on identical hardware. --------------enig6CEE54D3F0BA2EC9C26BE77C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHesJIldnAQVacBcgRAh0NAKCh8a3gVrMwd/bPFJ6GSl7Vu4G8TQCfa3pg yDywMHr2UNqIGWAWdNKVo58= =Evqg -----END PGP SIGNATURE----- --------------enig6CEE54D3F0BA2EC9C26BE77C-- From owner-freebsd-performance@FreeBSD.ORG Tue Jan 1 22:51:50 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 4A33C16A417 for ; Tue, 1 Jan 2008 22:51:50 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id EDD4F13C44B for ; Tue, 1 Jan 2008 22:51:49 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J9pxW-00045I-1Y for freebsd-performance@freebsd.org; Tue, 01 Jan 2008 22:51:42 +0000 Received: from 78-1-101-174.adsl.net.t-com.hr ([78.1.101.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2008 22:51:42 +0000 Received: from ivoras by 78-1-101-174.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2008 22:51:42 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Tue, 01 Jan 2008 23:51:35 +0100 Lines: 56 Message-ID: References: <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <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> <20080101122038.S9795@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig53008F8958A7B025C4DEDF62" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-101-174.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <20080101122038.S9795@delplex.bde.org> X-Enigmail-Version: 0.95.5 Sender: news 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 22:51:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig53008F8958A7B025C4DEDF62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bruce Evans wrote: > FreeBSD has more layers, with less optimization in each layer. Normall= y > this doesn't matter, since everyone knows that syscalls are expensive > and avoids them :-). My point is that the majority of applications are written for Linux and they are both syscall-intensive and faster there, so maybe something can be done in FreeBSD. > No Pipe-based Context Switching? That should be included in benchmarks= to > show FreeBSD slowness :-), since it is affected by both slow syscalls a= nd > slow context switches. Unfortunately, I found out this one on my own application. > Um, execl and process creation are not syscall-intensive. They take ab= out > 1 syscall each. Yes, in what amounts to a tight loop. They don't try to measure syscalls directly but I'd say they are intensive. > Linux wins this benchmark by a lot mainly because too much weight is gi= ven > to the file copy benchmarks In this particular instance I don't care about file system performance (and I believe that unixbench's benchmarks are outdated in this way and measure more of the file system cache than they should). Though it would be nice to have a FreeBSD file system that doesn't suck :) --------------enig53008F8958A7B025C4DEDF62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHesP4ldnAQVacBcgRAnpSAJ9yS1wBPTPCe8f05U4Ss/B5X1IQAACfZ/eF 8NX5KHwLhBIF2Y1SDdgqQPk= =6AM9 -----END PGP SIGNATURE----- --------------enig53008F8958A7B025C4DEDF62-- From owner-freebsd-performance@FreeBSD.ORG Wed Jan 2 04:08:34 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 3416516A417 for ; Wed, 2 Jan 2008 04:08:34 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0456813C458 for ; Wed, 2 Jan 2008 04:08:33 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so5564323rvb.43 for ; Tue, 01 Jan 2008 20:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ER7hIr/CBBp+S88wy+yOGOmXnWkGYWSA+JXF43T3DMw=; b=qLr0sGpMKfT3dEfkYXj6iY4QIYKh/YshTYZ76LQBgLe1+RNXXW+NXZgW7upcM3YJgZedDGJRj95r+sgILQ0xmixxa5ltnGd3fNcJomqqAnGPDi93Vr/6UWVrC6fOc0DlR0N5PBr3absL5JP+8J9B2VitPG9Nufl2VxWMV2HnUkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F17krv8kR6/23X7YmHY07xd+BeKAllxiQlIKLoBm/WZQBlH363iPUlwW88qr6LyOfqzBNdI/4Xw4GFi7zD7sI4ZA4TZ2o13DKwlXEAdoa8pppJZfvQiOnK5LpCWG0aXT816hTyBW22EGtYgrohLNlyjgjIJxE3JiF6fGIu81KNQ= Received: by 10.142.104.9 with SMTP id b9mr3809936wfc.48.1199246912808; Tue, 01 Jan 2008 20:08:32 -0800 (PST) Received: by 10.142.255.9 with HTTP; Tue, 1 Jan 2008 20:08:32 -0800 (PST) Message-ID: <8cb6106e0801012008q18830aebp906ebfeb3c519e5a@mail.gmail.com> Date: Tue, 1 Jan 2008 23:08:32 -0500 From: "Josh Carroll" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071201205609.GA54238@harmless.hu> <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> Cc: freebsd-performance@freebsd.org Subject: Re: mysql scaling questions X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2008 04:08:34 -0000 > Does anyone have a theory why syscalls are so expensive in FreeBSD? Here > are the results of unixbench 4.1 on two machines. First is the machine > running FreeBSD HEAD (debugging disabled) on a dual-core Athlon 64 (i386 > mode), 2 GHz: I ran the syscall benchmark from UnixBench on the same hardware (Intel Q6600 @ 3.2 GHz) for both FreeBSD 7.0-RC1 (amd64) and Knoppix 5.1 (Linux 2.6.9 PREEMPT kernel, i386). Per the comments in this thread, i386 syscalls should be less expensive than amd64 syscalls, so the results are interesting: FreeBSD 7.0-RC1 (amd64): System Call Overhead 15000.0 1103233.7 735.5 Knoppix Linux 2.6.9 (i686): System Call Overhead 15000.0 1108869.7 739.2 I can try to find a Linux live CD with a 2.6.x x86-64 kernel for a valid apples-to-apples comparison, but thought these results might provide some parity/insight. Doesn't look like the syscalls are slower at all on FreeBSD. Josh From owner-freebsd-performance@FreeBSD.ORG Wed Jan 2 11:00:05 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 AD3FE16A4A9; Wed, 2 Jan 2008 11:00:05 +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 02CD713C448; Wed, 2 Jan 2008 11:00:03 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477B6EB3.50202@FreeBSD.org> Date: Wed, 02 Jan 2008 12:00:03 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: josh.carroll@gmail.com References: <20071201205609.GA54238@harmless.hu> <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> <8cb6106e0801012008q18830aebp906ebfeb3c519e5a@mail.gmail.com> In-Reply-To: <8cb6106e0801012008q18830aebp906ebfeb3c519e5a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Wed, 02 Jan 2008 11:00:05 -0000 Josh Carroll wrote: >> Does anyone have a theory why syscalls are so expensive in FreeBSD? Here >> are the results of unixbench 4.1 on two machines. First is the machine >> running FreeBSD HEAD (debugging disabled) on a dual-core Athlon 64 (i386 >> mode), 2 GHz: > > I ran the syscall benchmark from UnixBench on the same hardware (Intel > Q6600 @ 3.2 GHz) for both FreeBSD 7.0-RC1 (amd64) and Knoppix 5.1 > (Linux 2.6.9 PREEMPT kernel, i386). > > Per the comments in this thread, i386 syscalls should be less > expensive than amd64 syscalls, so the results are interesting: > > FreeBSD 7.0-RC1 (amd64): System Call Overhead > 15000.0 1103233.7 735.5 > Knoppix Linux 2.6.9 (i686): System Call Overhead > 15000.0 1108869.7 739.2 > > I can try to find a Linux live CD with a 2.6.x x86-64 kernel for a > valid apples-to-apples comparison, but thought these results might > provide some parity/insight. > > Doesn't look like the syscalls are slower at all on FreeBSD. > > Josh > _______________________________________________ > 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" > > Per later discussion you will also need to either comment out the syscalls that are (might be) being cached by glibc to artificially inflate its reported rate, or verify that it is not doing so. Kris From owner-freebsd-performance@FreeBSD.ORG Wed Jan 2 11:03:05 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 E42EC16A469 for ; Wed, 2 Jan 2008 11:03:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id B33F513C448 for ; Wed, 2 Jan 2008 11:03:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so5684491rvb.43 for ; Wed, 02 Jan 2008 03:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=BWA6sodqToBz+kfDdB/LgYMixcb2+dJxLXUSUDwbpXA=; b=PqpQhre93HlibvYv629A30nQ2aW8L6Bz2IqSDZgzgEDsV0PypHj21O/VhkdDkglHa1s6FIre8DnL2ivmYPlaArcB7MYSSyKOa+S83BmWFFoImxg+xBW6RijV6LJhu4nicMiA7rvclwnXPJ23cuPszWQBmoTw3c1K56DCg/j4Vb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=f1HWuG39+qGLAdIRlzjqMgZNmpOifv87bG2rWxs1yRfs4RjNSAhx8nF52PuWuU9hXFp1hufdN1AUku+/EOdaVdd4LmBgoanZCV4NgVlcrmHoAuGY/CtIzPodB6K+Tbt/0Snt2HzJZ5RvnVVxw207T2WW3mJDQh9NvK8SkXNZT4I= Received: by 10.141.171.6 with SMTP id y6mr4898616rvo.174.1199270103684; Wed, 02 Jan 2008 02:35:03 -0800 (PST) Received: by 10.141.212.1 with HTTP; Wed, 2 Jan 2008 02:35:03 -0800 (PST) Message-ID: <9bbcef730801020235r634fc67bo1239b9626da13fa2@mail.gmail.com> Date: Wed, 2 Jan 2008 11:35:03 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: josh.carroll@gmail.com In-Reply-To: <8cb6106e0801012008q18830aebp906ebfeb3c519e5a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071201205609.GA54238@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> <8cb6106e0801012008q18830aebp906ebfeb3c519e5a@mail.gmail.com> X-Google-Sender-Auth: 26576755f5079c28 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: Wed, 02 Jan 2008 11:03:06 -0000 On 02/01/2008, Josh Carroll wrote: > > Does anyone have a theory why syscalls are so expensive in FreeBSD? Here > > are the results of unixbench 4.1 on two machines. First is the machine > > running FreeBSD HEAD (debugging disabled) on a dual-core Athlon 64 (i386 > > mode), 2 GHz: > > I ran the syscall benchmark from UnixBench on the same hardware (Intel > Q6600 @ 3.2 GHz) for both FreeBSD 7.0-RC1 (amd64) and Knoppix 5.1 > (Linux 2.6.9 PREEMPT kernel, i386). > > Per the comments in this thread, i386 syscalls should be less > expensive than amd64 syscalls, so the results are interesting: > > FreeBSD 7.0-RC1 (amd64): System Call Overhead > 15000.0 1103233.7 735.5 > Knoppix Linux 2.6.9 (i686): System Call Overhead > 15000.0 1108869.7 739.2 > Doesn't look like the syscalls are slower at all on FreeBSD. Thanks, I'll have to look further to see where the slowdowns are. From owner-freebsd-performance@FreeBSD.ORG Wed Jan 2 12:39:02 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 B592016A46B; Wed, 2 Jan 2008 12:39:02 +0000 (UTC) (envelope-from gary@velocity-servers.net) Received: from longhorn.velocity-servers.net (longhorn.velocity-servers.net [65.99.246.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB6213C448; Wed, 2 Jan 2008 12:39:02 +0000 (UTC) (envelope-from gary@velocity-servers.net) Received: from pool-70-106-59-217.hag.east.verizon.net ([70.106.59.217] helo=dragoon.velocity-servers.net) by longhorn.velocity-servers.net with esmtpa (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JA2PN-000Oif-QN; Wed, 02 Jan 2008 06:09:18 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Jan 2008 07:09:13 -0500 To: Kris Kennaway ,josh.carroll@gmail.com From: Gary Stanley In-Reply-To: <477B6EB3.50202@FreeBSD.org> References: <20071201205609.GA54238@harmless.hu> <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> <8cb6106e0801012008q18830aebp906ebfeb3c519e5a@mail.gmail.com> <477B6EB3.50202@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - longhorn.velocity-servers.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [26 6] / [26 6] X-AntiAbuse: Sender Address Domain - velocity-servers.net Message-Id: <20080102123902.8CB6213C448@mx1.freebsd.org> X-Mailman-Approved-At: Wed, 02 Jan 2008 13:31:41 +0000 Cc: 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: Wed, 02 Jan 2008 12:39:02 -0000 At 06:00 AM 1/2/2008, Kris Kennaway wrote: >Per later discussion you will also need to either comment out the >syscalls that are (might be) being cached by glibc to artificially >inflate its reported rate, or verify that it is not doing so. > >Kris IIRC linux uses vsyscalls on x86_64, and calling things like gettimeofday() isn't as expensive as it normally should be.. vsyscalls are similar to darwins' commpage. -G From owner-freebsd-performance@FreeBSD.ORG Wed Jan 2 15:16:33 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 5950016A46B; Wed, 2 Jan 2008 15:16:33 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 0CBD813C447; Wed, 2 Jan 2008 15:16:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54BD9.dip.t-dialin.net [84.165.75.217]) by redbull.bpaserver.net (Postfix) with ESMTP id 6812F2E334; Wed, 2 Jan 2008 16:00:02 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 3E22E785FD; Wed, 2 Jan 2008 15:59:57 +0100 (CET) Date: Wed, 2 Jan 2008 15:52:47 +0100 From: Alexander Leidinger To: Gergely CZUCZY Message-ID: <20080102155247.25d23a61@deskjail> In-Reply-To: <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> <20080101142116.GA94325@harmless.hu> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; i686-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Vlad, Kris Kennaway , GALU , 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: Wed, 02 Jan 2008 15:16:33 -0000 Quoting Gergely CZUCZY (Tue, 1 Jan 2008 15:21:16 +0100): > 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... http://www.freebsd.org/projects/ideas/#p-ports-comp43tty -- BOFH excuse #15: temporary routing anomaly http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-performance@FreeBSD.ORG Wed Jan 2 23:56:57 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 2400116A417; Wed, 2 Jan 2008 23:56:57 +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 ECA7E13C458; Wed, 2 Jan 2008 23:56:56 +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 m02Nun9H009381; Wed, 2 Jan 2008 18:56:54 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 2 Jan 2008 13:58:10 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Bruce Evans In-Reply-To: <20080102084139.X12725@delplex.bde.org> Message-ID: <20080102135221.E957@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> <20080101022655.S957@desktop> <20080102084139.X12725@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Gergely CZUCZY , 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: Wed, 02 Jan 2008 23:56:57 -0000 On Wed, 2 Jan 2008, Bruce Evans wrote: > On Tue, 1 Jan 2008, Jeff Roberson wrote: > >> On Tue, 1 Jan 2008, Gergely CZUCZY wrote: > >>> 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. > > No, syscalls on i386 UP take about 65 cyles _less_ than on amd64, due It is true that we are slower on i386 by not using sysenter and on par on 64bit amd64. > mainly to 64-bit code and data being larger. A syscall takes about > 385 cycles on an A64 running i386 UP (0.17us @ 2.205GHz), so it can't > possibly take 750 cycles more than on the same A64 running amd64 UP > (0.20us @ 2.205GHz). I think SYSENTER/SYSEXIT saves more like 7.5 or > 75 cycles and thus compensates for some of the 64-bit overhead, else > amd64 would be even slower. I don't have documents or measurements > for current int0x80 or SYS* times -- on i486, int0x80 takes about 80 > cycles and iret takes about the same, so the total overhead from the > bad hardware interface is about half of the total syscall overerhead. I have not benchmarked since the P4 days so my data must be grossly out of date. At the time I had a small operating system that I used for benchmarking processor features. I also tested call gates, task gates, etc. I might be confusing the results of one of these tests. Thanks, Jeff > > The times 0.17us and 0.20us are from lmbench2 doing a COMPAT_43 getppid(). > As is well known, getppid() is a better benchmark than getpid() since it > is much harder for libraries to cache (since the parent may change to > init at any time). In FreeBSD, it always does proc locking, while getpid() > only does proc locking if COMPAT_43. But the overhead for uncontested > locking on UP is in the noise -- it is about 5-10 cycles on this hardware. > > lmbench2 is not up to date enough enough to report things with nanoseconds > resolution. I have more accurate measurements for clock_gettime(). > After some optimizations, clock_gettime() timing itself takes an average > of 233ns in my version of 5.2 and 250-260ns in -current, both on i386 UP > @2.205GHz. > > Linux-2.6.10 i386 UP takes 0.13us for getpid() on slightly different > hardware (AXP 2.223GHz) where FreeBSD i386 UP takes slightly longer > than on the A64 (0.17-0.18us). Not a big difference. The difference > is more interesting for the even-more-bogus "null I/O" micro-benchmark. > This writes 1 byte to /dev/null. Linux used to be 4-5 times faster on > this (on the AXP, in 0.16us in Linux-2.3.99 vs 0.90us in FreeBSD-~5.2), > but Linux has been speeded down (0.19us in Linux-2.6.10) and FreeBSD > has been speeded up (0.33us on the A64 in -current). I consider the > speedups bogus since they consist of combining/avoiding vfs layers for > devices only. The usual case of (cached) file i/o remains unnecessarily > slow. (For most devices, and for uncached file i/o, the hardware part is > necessarily slow, so optimization of the software hardly matters.) > > Bruce > _______________________________________________ > 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" > From owner-freebsd-performance@FreeBSD.ORG Thu Jan 3 02:46:48 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 6914316A418; Thu, 3 Jan 2008 02:46:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id DB4F113C459; Thu, 3 Jan 2008 02:46:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m032khu6028452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 13:46:45 +1100 Date: Thu, 3 Jan 2008 13:46:43 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Gary Stanley In-Reply-To: <20080102123902.8CB6213C448@mx1.freebsd.org> Message-ID: <20080103134118.G16729@delplex.bde.org> References: <20071201205609.GA54238@harmless.hu> <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> <8cb6106e0801012008q18830aebp906ebfeb3c519e5a@mail.gmail.com> <477B6EB3.50202@FreeBSD.org> <20080102123902.8CB6213C448@mx1.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: josh.carroll@gmail.com, 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: Thu, 03 Jan 2008 02:46:48 -0000 On Wed, 2 Jan 2008, Gary Stanley wrote: > At 06:00 AM 1/2/2008, Kris Kennaway wrote: > >> Per later discussion you will also need to either comment out the syscalls >> that are (might be) being cached by glibc to artificially inflate its >> reported rate, or verify that it is not doing so. > > IIRC linux uses vsyscalls on x86_64, and calling things like gettimeofday() > isn't as expensive as it normally should be.. vsyscalls are similar to > darwins' commpage. How does it implement gettimeofday()'s 1us precision using direct access? I see one way: put the time and other volatiles on an unmapped page, and update the time in the trap handler. With a lot of work, this should be only slightly slower than the gettimeofday() syscall. Bruce From owner-freebsd-performance@FreeBSD.ORG Thu Jan 3 21:52:39 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 6875E16A41A for ; Thu, 3 Jan 2008 21:52:39 +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 8746B13C465; Thu, 3 Jan 2008 21:52:38 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477D5927.4030100@FreeBSD.org> Date: Thu, 03 Jan 2008 22:52:39 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gergely CZUCZY References: <20071129101729.GA57985@harmless.hu> <20071130143023.I884@192.168.1.107> <20071201163334.GA21709@harmless.hu> <200712012055.lB1Kt5IQ005728@lava.sentex.ca> <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <20071204130810.GA77186@harmless.hu> <47779AA7.2060801@FreeBSD.org> <20071230132451.GA61295@harmless.hu> In-Reply-To: <20071230132451.GA61295@harmless.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , 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: Thu, 03 Jan 2008 21:52:39 -0000 Gergely CZUCZY wrote: >> * Compare to my config file here: >> >> http://people.freebsd.org/~kris/scaling/my.cnf >> >> The default mysql config has very poor performance for innodb (you need at least innodb_thread_concurrency = 0 to disable some mysql >> brain-death). Maybe tuning is required for myisam also. >> >> * Also make sure you are using identical config settings on the two systems. > http://phoemix.harmless.hu/mysql/ verify yourself. Only the paths are > updated, but the main parameters are just the same. You are not in fact using the same config parameters as I am. When I use your config file I see a large performance loss when I run locally even with innodb. Kris From owner-freebsd-performance@FreeBSD.ORG Thu Jan 3 22:08:05 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 181F216A419; Thu, 3 Jan 2008 22:08:05 +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 8DDAA13C465; Thu, 3 Jan 2008 22:08:04 +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 941487C18B3; Thu, 3 Jan 2008 23:08:01 +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 o3m8ORb3S2Ye; Thu, 3 Jan 2008 23:08:01 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id BD3A17C18B7; Thu, 3 Jan 2008 23:07:58 +0100 (CET) Date: Thu, 3 Jan 2008 23:07:58 +0100 From: Gergely CZUCZY To: Kris Kennaway Message-ID: <20080103220757.GA86719@harmless.hu> References: <20071201163334.GA21709@harmless.hu> <200712012055.lB1Kt5IQ005728@lava.sentex.ca> <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <20071204130810.GA77186@harmless.hu> <47779AA7.2060801@FreeBSD.org> <20071230132451.GA61295@harmless.hu> <477D5927.4030100@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <477D5927.4030100@FreeBSD.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Jeff Roberson , 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: Thu, 03 Jan 2008 22:08:05 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote: > Gergely CZUCZY wrote: >=20 > >>* Compare to my config file here: > >> > >>http://people.freebsd.org/~kris/scaling/my.cnf > >> > >>The default mysql config has very poor performance for innodb (you need= at least innodb_thread_concurrency =3D 0 to disable some mysql=20 > >>brain-death). Maybe tuning is required for myisam also. > >> > >>* Also make sure you are using identical config settings on the two sys= tems. > >http://phoemix.harmless.hu/mysql/ verify yourself. Only the paths are > >updated, but the main parameters are just the same. >=20 > You are not in fact using the same config parameters as I am. When I use= your config file I see a large performance loss when I run=20 > locally even with innodb. Well, I nowhere said that I'm using the same config as you did. In fact, I = said I was using the config from the production system we've got, and what were the differences in the config between the FreeBSD and the Linux systems. As soon as I have the time, I will make a diff and make some adjustments and new results with the updated config. We will see where this gets :) Thanks for the note on this. Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owF1VL9vHEUUNonSrEjhNtUrkIKd2707nxPsi+4SY5PoSKIg+ZCVAIrmdt/uDp4f 65nZW28E1CkoEAUUCITokRKJNoIOJCRq/gIkJEpQChre7N7ZTkFz2ps3873v+943 89nF8yvnVn97+sN7Vz79/KtXvr/w02xdls6pLJTMzLkK+71eP9y69kZ/O9wMB0m8 kQ6ubfYHV/ub2/Htj99/vquVQ+XCaV3gEBweu24hGFfXIc6ZsehGpUvDrWC5b4/b QlvuuFZD4EpwhSe1qWHKpmjCt1SsE66yIRyV2mESFoYrx2YCg+C+gmleduBtpqA3 6MBGr7cFzEG/N7y6MRxsv3MPrvSIdQfuGG7hDirFKlZDZQhpGIzhNpoMRQ27D9/d ffjgZH200aPieLwOu1oWzCA4DbKGWKuUZ5BygZCjaSDG4+Ynd64YdrsF6kJglBrE mU0ibbLuJ4fUu2tjRvqyrqyjWKWn56Y5QoIpK4WjDvZILJvkzMIcTQ2F1gYKNKk2 kqkYgT7ILaWTGbxe6xIUYjIKvG6BzLpF7ZHLDbLkEcHFpTGo4hpGgz3oeS0Jt95B sFpi23YpeWZoYGGCzOVrEcA9Vs9IfamIO5CFBo9KbjBpSMiaYCQwYXV0qmgddmgB JDsk/JK88xy9h6VtQBIaLyc3lkIpF44KFrQCR264SoOt7ShwKG2Du/Q21yj5cURZ kgKtjfKy23DveqN4WvtOFDORRnBf0VQ9WkFCrG/vgcoiYRShDsxK11QliaUthkl0 aJp98GFp2yJpw2gZhgcLEUp7gyFlsVsIWm5d6jkLZ2ECTJKPBzkq+i4t0qQ8zZey NCETEBgIRnF8adZCWwtVe9iUquUiNNlH+nBO6xV3+WLkUXCAQnRoq9KVzyfx4gkR pGhMLsv/4Usk/YQSnkQwaZV5iFHgDwcTqGjD6cklbaNl66/RSRn7K+yHRiODCi/P ETJNKEwlRJ66V0Qm8NsTntKlpjCi9TaeQZyhqxDbpVt0fd7c32vO+/93uSqPF/gU iWDHUnKpY+NvzqhdExwu0TOvuBBt/FjTr4Fp4+jjzhI/YUkptL4SKKwo1pYuoG3N 9FiLpCzIRXCALayfU2uty+k6ZEiHhmtBMM2ZOrTNrfDHKSXY5pl7vvucBBt6aDpB cPLkPC7jx3VACRRODwmpWY7iZvnmmYwHQRj6uR+QO5xsc2hdRC+X4pQmb4SYN2Og +yxtO2xGLw5F98mN8xdW/MO8fNRXz/310cq33/34/O4X4/1/nt28cf2btT+/fFW/ uLjy9erOr09+/v3pH9nfr30wzH6ZvHj276X/AA== =7c/j -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-performance@FreeBSD.ORG Fri Jan 4 13:30:34 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 4D20116A418; Fri, 4 Jan 2008 13:30:34 +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 C51A513C4E1; Fri, 4 Jan 2008 13:30:33 +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 544EB7C0F59; Fri, 4 Jan 2008 14:30:31 +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 GTsu4pylUHNB; Fri, 4 Jan 2008 14:30:30 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 837647C0BDE; Fri, 4 Jan 2008 14:30:28 +0100 (CET) Date: Fri, 4 Jan 2008 14:30:28 +0100 From: Gergely CZUCZY To: Kris Kennaway Message-ID: <20080104133028.GA89602@harmless.hu> References: <20071201163334.GA21709@harmless.hu> <200712012055.lB1Kt5IQ005728@lava.sentex.ca> <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <20071204130810.GA77186@harmless.hu> <47779AA7.2060801@FreeBSD.org> <20071230132451.GA61295@harmless.hu> <477D5927.4030100@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <477D5927.4030100@FreeBSD.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Jeff Roberson , 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: Fri, 04 Jan 2008 13:30:34 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote: > Gergely CZUCZY wrote: >=20 > >>* Compare to my config file here: > >> > >>http://people.freebsd.org/~kris/scaling/my.cnf > >> > >>The default mysql config has very poor performance for innodb (you need= at least innodb_thread_concurrency =3D 0 to disable some mysql brain-death= ). =20 > >>Maybe tuning is required for myisam also. > >> > >>* Also make sure you are using identical config settings on the two sys= tems. > >http://phoemix.harmless.hu/mysql/ verify yourself. Only the paths are > >updated, but the main parameters are just the same. >=20 > You are not in fact using the same config parameters as I am. When I use= your config file I see a large performance loss when I run locally even wi= th=20 > innodb. So, the updated config is here: http://phoemix.harmless.hu/mysql/my.cnf.kris I've migrated the values from your config. And the plot is here: http://phoemix.harmless.hu/mysql/rw-kris.png I"ve also plotted a current production system, which crashes around 96 thre= ads in the test, or so. That's a Linux-2.6.12 and MySQL 5.0.22, so it should be qu= ite unoptimized compared to any recent version of anything. As it seems, you were right. These adjustments made a very slight performan= ce boost, around 5%. But it's still lagging behind. Again, this is MyISAM, not innodb. The "tc4" and "tc16" strings mean the th= read_concurrency is either set to 4 or 16. Your config had 16, but I've googled for it, and = some resources suggested setting that to CPUs*2, and that's 4 in my case. I've updated the MySQL version on FreeBSD to 5.0.51, and will try to get th= is version on linux also, and do a comparision with that one, too. Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owGNVU1vHEUQNYkQUiMO4QyiZAkFnJ3ZD9sbe9E6ODZYxrESZIeQ5BD1ztTMdDLT Pe7u8WZySA5cckACccgFIc5IIHEACYkfwAVx4cJv4IIQ/ACqZnbthAtIljXbH6/q vXpV/elLZxfOnPvl2+9uX/j4s8+f++aFXycXisp7nQaFtMdKB/1erx+srQ97g2AY 9FeGUf9iNFm+uJb0J/HKzsOVv7aM9qh9cFiXOAKP9323zKXSb0GUSevQjyufBGti fm5budI45ZXRI1A6VxpP9g6t1C5BG7yjIxMrnY7gqDIe46C0Sns5yVGIqxoOs6oD 70kNveUODHq9NZAe+r3R6mC0vH5tHy70KO0O7FnlYA+1llNZw9QS0khswA7aFPMa tm5d37p182R9POjR5sbGEmyZopQWwRsoaoiMTlQKicoRMrQNxMZG8y/zvhx1uyWa MscwsYgTF4fGpt2H9yh210WS+KXdog4jnZzeO8wQYkxklXuK4I7yeZBMOjhGW0Np jIUSbWJsIXWEQB+kljbxBN6oTQUaMR4L5p2jdH62d8dnFmV8h+CiylrUUQ3j5W3o MZdYOVYQnClwFnZiqVJBjNJnY/FmCHMN9mU9If6VpuyBRLR4VCmLcZNGURNQATJ3 JjzltASbtACFvEcRKlKPs2QVK9eAxFRgRXrMqZIzPG04MBo86eGnBlztxsJj4Rrc ubqZwULdD8lNRY7OhVnVbbLvslQqqTkSGS1PQriqqa6MVhIjx+EZqCpjSSbqwKTy zW5BrOmIlQV6tM05uFu5dpO4YTi3w80ZCW1YYkhk5GeE5kfnfJ6Gc7ALsggBbmSo 6btySLXiNJ9x0y6JgCAhl2TIZ6qdG+dg2l62labfpBxRw2NamioSKWvza8seigPT aTKaUZ2HodK1lv1PLVuLhmxbIXbPH5NIKrUNFuMey7xCB4k1xdM8QiE2dXuizFmi /x3PTgOOFZY6pXiLFI/91KBwTAmtfz2U1sRVxOOC7UHm6JAwKsogstJlyMUzFeWw PgQ2/1jI2JEsovEUOt8Bsiw5lYaG9OfpOFxRurofDMJh2B+ApKv79cH7V2A17IWD QYfOgvLgMlPlMVAXHFVjoTxJq03pVaEeYCyidkLE3FZS19QfEedKfnScqEl41Wfk E1bINYBIvu40XTElicCqNPOcFTriHrP9CsJwZM6YTdGMAZfzqVNrjAWZY2IM02p5 i9XXQ7hMvlZMznmV5+SnNGWLTpAyiDmDlAzPBqH60N9+vXuwud+ZmboxEOcBiz5a WWwUoa/+cJHgbNOiBcpZk9KY+PeAEYSIinYt9zQrssKS94chd489HW0xrbU92Pgr NSbNZyNFMR+KOxbNcLLo6GaETrgqTamIdGw2LygF2QTZunbdLQ3aa74t7Qq3KE9s 6aiDWxfPG4Kzb+t8UiQN79LEvnywzXBc/dV+CzdlET3JT+spUyLWys0vCrqYs4Ua x7Y3YsOObUyhGvApCdKmajSS8oZGpThQ1NuWnp6OECeP0IMqelALmki5NyMK1yyH UbP89lN9I0QQcM/fQNSKbM/eDukt04qmC1Xe5MSWmoUmfOHa0JwMCfH40tnnF/ip nr/z58789sfClzd+ePLz4PpXn7z20aOdnx5/8OTuj79fWvji1Udnlr5+8fuXP+wO b/95rfNKtLf09z8= =k3X4 -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-performance@FreeBSD.ORG Fri Jan 4 19:33:10 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 B478216A420 for ; Fri, 4 Jan 2008 19:33:10 +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 291B913C442; Fri, 4 Jan 2008 19:33:08 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477E89F4.1080605@FreeBSD.org> Date: Fri, 04 Jan 2008 20:33:08 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gergely CZUCZY References: <20071201163334.GA21709@harmless.hu> <200712012055.lB1Kt5IQ005728@lava.sentex.ca> <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <20071204130810.GA77186@harmless.hu> <47779AA7.2060801@FreeBSD.org> <20071230132451.GA61295@harmless.hu> <477D5927.4030100@FreeBSD.org> <20080104133028.GA89602@harmless.hu> In-Reply-To: <20080104133028.GA89602@harmless.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , 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: Fri, 04 Jan 2008 19:33:10 -0000 Gergely CZUCZY wrote: > On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote: >> Gergely CZUCZY wrote: >> >>>> * Compare to my config file here: >>>> >>>> http://people.freebsd.org/~kris/scaling/my.cnf >>>> >>>> The default mysql config has very poor performance for innodb (you need at least innodb_thread_concurrency = 0 to disable some mysql brain-death). >>>> Maybe tuning is required for myisam also. >>>> >>>> * Also make sure you are using identical config settings on the two systems. >>> http://phoemix.harmless.hu/mysql/ verify yourself. Only the paths are >>> updated, but the main parameters are just the same. >> You are not in fact using the same config parameters as I am. When I use your config file I see a large performance loss when I run locally even with >> innodb. > So, the updated config is here: > http://phoemix.harmless.hu/mysql/my.cnf.kris > > I've migrated the values from your config. > > And the plot is here: > http://phoemix.harmless.hu/mysql/rw-kris.png > > I"ve also plotted a current production system, which crashes around 96 threads in > the test, or so. That's a Linux-2.6.12 and MySQL 5.0.22, so it should be quite unoptimized > compared to any recent version of anything. > > As it seems, you were right. These adjustments made a very slight performance boost, around > 5%. But it's still lagging behind. > > Again, this is MyISAM, not innodb. The "tc4" and "tc16" strings mean the thread_concurrency > is either set to 4 or 16. Your config had 16, but I've googled for it, and some resources > suggested setting that to CPUs*2, and that's 4 in my case. > > I've updated the MySQL version on FreeBSD to 5.0.51, and will try to get this version > on linux also, and do a comparision with that one, too. > > Sincerely, > > Gergely Czuczy > mailto: gergely.czuczy@harmless.hu > OK. The caching problem with myisam is unrelated to the other config changes then. Kris From owner-freebsd-performance@FreeBSD.ORG Fri Jan 4 19:35:56 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 6B53F16A419; Fri, 4 Jan 2008 19:35:56 +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 0465613C45B; Fri, 4 Jan 2008 19:35:50 +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 D16AC7C0AF3; Fri, 4 Jan 2008 20:35:48 +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 nBxx0yegr69g; Fri, 4 Jan 2008 20:35:48 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 6032C7BFC08; Fri, 4 Jan 2008 20:35:46 +0100 (CET) Date: Fri, 4 Jan 2008 20:35:46 +0100 From: Gergely CZUCZY To: Kris Kennaway Message-ID: <20080104193546.GA34364@harmless.hu> References: <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <20071204130810.GA77186@harmless.hu> <47779AA7.2060801@FreeBSD.org> <20071230132451.GA61295@harmless.hu> <477D5927.4030100@FreeBSD.org> <20080104133028.GA89602@harmless.hu> <477E89F4.1080605@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <477E89F4.1080605@FreeBSD.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Jeff Roberson , 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: Fri, 04 Jan 2008 19:35:56 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2008 at 08:33:08PM +0100, Kris Kennaway wrote: > Gergely CZUCZY wrote: > >On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote: > >>Gergely CZUCZY wrote: > >> > >>>>* Compare to my config file here: > >>>> > >>>>http://people.freebsd.org/~kris/scaling/my.cnf > >>>> > >>>>The default mysql config has very poor performance for innodb (you ne= ed at least innodb_thread_concurrency =3D 0 to disable some=20 > >>>>mysql brain-death). Maybe tuning is required for myisam also. > >>>> > >>>>* Also make sure you are using identical config settings on the two s= ystems. > >>>http://phoemix.harmless.hu/mysql/ verify yourself. Only the paths are > >>>updated, but the main parameters are just the same. > >>You are not in fact using the same config parameters as I am. When I u= se your config file I see a large performance loss when I run=20 > >>locally even with innodb. > >So, the updated config is here: > >http://phoemix.harmless.hu/mysql/my.cnf.kris > >I've migrated the values from your config. > >And the plot is here: > >http://phoemix.harmless.hu/mysql/rw-kris.png > >I"ve also plotted a current production system, which crashes around 96 t= hreads in > >the test, or so. That's a Linux-2.6.12 and MySQL 5.0.22, so it should be= quite unoptimized > >compared to any recent version of anything. > >As it seems, you were right. These adjustments made a very slight perfor= mance boost, around > >5%. But it's still lagging behind. > >Again, this is MyISAM, not innodb. The "tc4" and "tc16" strings mean the= thread_concurrency > >is either set to 4 or 16. Your config had 16, but I've googled for it, a= nd some resources > >suggested setting that to CPUs*2, and that's 4 in my case. > >I've updated the MySQL version on FreeBSD to 5.0.51, and will try to get= this version > >on linux also, and do a comparision with that one, too. > >Sincerely, > >Gergely Czuczy > >mailto: gergely.czuczy@harmless.hu >=20 > OK. The caching problem with myisam is unrelated to the other config cha= nges then. I have to finish my test, sorry for not being able to give more results. The boss decided to put back this box to the serverfarm, and since we're not using FreeBSD, just I'm a bsd-guy, I won't be able to do anything farth= er on on this topic. I hope I did something useful with this tests of my at all. And thank you all for helping with all the ideas, especially to you, Kris. Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) owGVVkGLHEUU3hjMoUEk4N3HgqwmM70zu7PLZmRWk43GNVk3sgkh8RBqul93l+mu 6lRV72znEPAiEkQSQT2IGLyLHjx48Dd49iIevAvqH/C9qp7NRpEoLEtPV9X33vve 977q+88cX3jq5I/ffvfO6Q8//vzY19H709NV45zK+5Uw+1L1h4PBsL86Wl0f9Tf6 o1E6HCaj1bUsW0+yLL1w996DLa0cKte/0tY4BocHbrkuhVQvQ1IIY9FNGpf1N6L5 vvPS1tpKJ7Uag1SlVHi4dsUIZTM0/ddUolOp8jHcbrTDtF8bqZyYlhhFuwpeN7IH bwoFg1EPVgaDDRAOBhvj1dXxYOPyDpweUNo9uGikhYuolJiJFmaGkMbRJlxAk2PZ wtaNq1s3rj96v0nIV4qmQ159hDwcjNdWxqtnnoi8ufmv2Jv+3+bmKdjSVS0MgtNQ tZBolckcMlkiFGi6zYfbC+fq8fJyjbouMc4M4tSmsTb58t1blMOyTQQxmC9XbZyo 7PGzVwqEFDPRlI4i2dvlPFghLOyjaaHW2kCNJtOmEipBoAfqidLpFF5sdQMKJxGm zEGJwrpu7aYrDIr0JsEljTGokhYmq+dhwDWl0nKfwOoKJyuDLpcQf2pIGP0UhSte igF2RDslHhpFFQARavB2Iw3F4zSqloAqEKXV8eN1nYKz9BIqcYuiNMQkZ8qMNtYD pSQlSbzMyyUNOlqwoBU44sTNNNhJ1FqHle2w5zwXGit5EJNyqxKtjYtm2ae+zITJ rOVYJOoyi2FXUZ8Zr6ZyLCcQoJo6FSTZHkwb59crKpo2GVGhQ+N3wruNDYtUI4Yc rndVKM08QyYS11U03zcv6CiWhW0QFZF5rUBFz80ksp4R85i0tokFBAGlIH0+1vJS WwuzcNg0at6yUhODVCDu08pMuqLrvc91T/d8Ul2p80jUwkMJP5HQoNiYVcz7t5f2 iSmZGw/I4PuibNBCZnR1tB6fwFkV9tQlk/V/wppZn0PGtcp92EUKyxrzUBxaQNC0 g9rotEnYqMB6sfSIJ5kUkBhhC+RG6oYSObMObhL5kbDEEsN6maF1PSAlk4DJV4Rb ohNwSarmoL8Sr8fDFRB0eqfde/sSrMWDeGWlR3tBOrCFbsoUpjR9ZIDSEdNK105W 8g6mjJ8ED0l54IRqaXISzpg0ajldnfFbV5B4Al3WoyLpveenZUZ8gZF54Tg1JMWI lCVZEYolwaasFW8RtuRdnWImUdDMVGuuLdTPAdZeiOEcyV1ykdbJsiSl5TmLd4qU RhrSyGkSWDnUMfrbabf3zu70OsF7cXEysOiS0aLnhp6G64sEaPz8Vij8BBMr/3Qg DkCgSFJFwzPP3IyY/+F6DNePDEQhUnoX5tPLLtc6LzvbkVzXJKLgbGBErKWTCXqN 2ibPqam0s7MUSkP4OFuXr9pT1D7hdelbPeIhZoMXNgy4DzWfGBZI6Pxhz/haQzy3 d54BWQ9rwwA4Yzod9YLe53SfRoHB7iBD09mSdeWVHA6lmpXsZSI9vp9hn69WSE3Q wVb3JDXU0JXV41+H19edJrnjKSXzKp0eU2C/Eid+5dUjgxVtBs/YvUguxP1LRMLK 4/mhi6AKkTs7p7wbReECCdrzoH3HuubQRwOxTzTzkoqjaJv6te9vy0wqaRmpGy2r DZHCTWMFTZFj+quHeZJsJ9r4DtIFSD7PqU3Z7FJM6I7w4WuSwFQktwKjU30wz8mi IX4zqjLQaZkmGpslcnmOFoy5a1gv2Pn2El1XQPdzP2/aHtnpTKslTuwwq1QfziX5 u3EF3a4mCs33GThdyyQUrWt27VQGIYYzjcWsKeet5P1EhOVxJ1Kos+TYdDiYo1C3 wsVI4mGOCixrxvCH+SWXSTwIsgS0NXHi/d7piE6FLxzCOiKP6G/i+A/KiPp91sY1 RCUxZBvT55eSVAj5hC6pSZ1KbNAmq5XG5YNXjj+9wF+X80/Tk0+tf7Pw5W7724Of j/3x+wn5/Pf339i4d+K5t35aeHj/qz9v3/x14dkvfvnoh08ffrJoPlPv/QU= =xk3a -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-performance@FreeBSD.ORG Fri Jan 4 19:42:33 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 905DE16A46B for ; Fri, 4 Jan 2008 19:42:33 +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 BA15E13C459; Fri, 4 Jan 2008 19:42:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <477E8C26.6050002@FreeBSD.org> Date: Fri, 04 Jan 2008 20:42:30 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gergely CZUCZY References: <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <20071204130810.GA77186@harmless.hu> <47779AA7.2060801@FreeBSD.org> <20071230132451.GA61295@harmless.hu> <477D5927.4030100@FreeBSD.org> <20080104133028.GA89602@harmless.hu> <477E89F4.1080605@FreeBSD.org> <20080104193546.GA34364@harmless.hu> In-Reply-To: <20080104193546.GA34364@harmless.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , 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: Fri, 04 Jan 2008 19:42:33 -0000 Gergely CZUCZY wrote: > On Fri, Jan 04, 2008 at 08:33:08PM +0100, Kris Kennaway wrote: >> Gergely CZUCZY wrote: >>> On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote: >>>> Gergely CZUCZY wrote: >>>> >>>>>> * Compare to my config file here: >>>>>> >>>>>> http://people.freebsd.org/~kris/scaling/my.cnf >>>>>> >>>>>> The default mysql config has very poor performance for innodb (you need at least innodb_thread_concurrency = 0 to disable some >>>>>> mysql brain-death). Maybe tuning is required for myisam also. >>>>>> >>>>>> * Also make sure you are using identical config settings on the two systems. >>>>> http://phoemix.harmless.hu/mysql/ verify yourself. Only the paths are >>>>> updated, but the main parameters are just the same. >>>> You are not in fact using the same config parameters as I am. When I use your config file I see a large performance loss when I run >>>> locally even with innodb. >>> So, the updated config is here: >>> http://phoemix.harmless.hu/mysql/my.cnf.kris >>> I've migrated the values from your config. >>> And the plot is here: >>> http://phoemix.harmless.hu/mysql/rw-kris.png >>> I"ve also plotted a current production system, which crashes around 96 threads in >>> the test, or so. That's a Linux-2.6.12 and MySQL 5.0.22, so it should be quite unoptimized >>> compared to any recent version of anything. >>> As it seems, you were right. These adjustments made a very slight performance boost, around >>> 5%. But it's still lagging behind. >>> Again, this is MyISAM, not innodb. The "tc4" and "tc16" strings mean the thread_concurrency >>> is either set to 4 or 16. Your config had 16, but I've googled for it, and some resources >>> suggested setting that to CPUs*2, and that's 4 in my case. >>> I've updated the MySQL version on FreeBSD to 5.0.51, and will try to get this version >>> on linux also, and do a comparision with that one, too. >>> Sincerely, >>> Gergely Czuczy >>> mailto: gergely.czuczy@harmless.hu >> OK. The caching problem with myisam is unrelated to the other config changes then. > > I have to finish my test, sorry for not being able to give more results. > The boss decided to put back this box to the serverfarm, and since we're > not using FreeBSD, just I'm a bsd-guy, I won't be able to do anything farther > on on this topic. > > I hope I did something useful with this tests of my at all. > > And thank you all for helping with all the ideas, especially to > you, Kris. Thanks for bringing it up. If anyone else is interested it would be good to figure out if there is a way to improve the myisam caching behaviour. It is likely that performance will also improve once the lockmgr changes are completed. Kris From owner-freebsd-performance@FreeBSD.ORG Fri Jan 4 21:15:22 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 8AB2016A418 for ; Fri, 4 Jan 2008 21:15:22 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp814.mail.ird.yahoo.com (smtp814.mail.ird.yahoo.com [217.146.188.74]) by mx1.freebsd.org (Postfix) with SMTP id 07D1013C43E for ; Fri, 4 Jan 2008 21:15:21 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 93133 invoked from network); 4 Jan 2008 20:48:40 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.151.234.106 with plain) by smtp814.mail.ird.yahoo.com with SMTP; 4 Jan 2008 20:48:39 -0000 X-YMail-OSG: RSiTjgUVM1mje3rrzdTv0D.c0Atzft2CLHQOhuQYZ6KdFHrsaUFAqX.HLznoEvWUhutlQ1AWpDQSUhvF4zisyEk- Message-ID: <477E9C8A.8050302@tomjudge.com> Date: Fri, 04 Jan 2008 20:52:26 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Kris Kennaway References: <20071201205609.GA54238@harmless.hu> <200712012108.lB1L8qAd005766@lava.sentex.ca> <20071201211012.GA55519@harmless.hu> <20071201122122.S884@192.168.1.107> <20071204130810.GA77186@harmless.hu> <47779AA7.2060801@FreeBSD.org> <20071230132451.GA61295@harmless.hu> <477D5927.4030100@FreeBSD.org> <20080104133028.GA89602@harmless.hu> <477E89F4.1080605@FreeBSD.org> <20080104193546.GA34364@harmless.hu> <477E8C26.6050002@FreeBSD.org> In-Reply-To: <477E8C26.6050002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gergely CZUCZY , freebsd-performance@freebsd.org, Jeff Roberson 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: Fri, 04 Jan 2008 21:15:22 -0000 Kris Kennaway wrote: > Gergely CZUCZY wrote: >> On Fri, Jan 04, 2008 at 08:33:08PM +0100, Kris Kennaway wrote: >>> Gergely CZUCZY wrote: >>>> On Thu, Jan 03, 2008 at 10:52:39PM +0100, Kris Kennaway wrote: >>>>> Gergely CZUCZY wrote: >>>>> >>>>>>> * Compare to my config file here: >>>>>>> >>>>>>> http://people.freebsd.org/~kris/scaling/my.cnf >>>>>>> >>>>>>> The default mysql config has very poor performance for innodb >>>>>>> (you need at least innodb_thread_concurrency = 0 to disable some >>>>>>> mysql brain-death). Maybe tuning is required for myisam also. >>>>>>> >>>>>>> * Also make sure you are using identical config settings on the >>>>>>> two systems. >>>>>> http://phoemix.harmless.hu/mysql/ verify yourself. Only the paths are >>>>>> updated, but the main parameters are just the same. >>>>> You are not in fact using the same config parameters as I am. When >>>>> I use your config file I see a large performance loss when I run >>>>> locally even with innodb. >>>> So, the updated config is here: >>>> http://phoemix.harmless.hu/mysql/my.cnf.kris >>>> I've migrated the values from your config. >>>> And the plot is here: >>>> http://phoemix.harmless.hu/mysql/rw-kris.png >>>> I"ve also plotted a current production system, which crashes around >>>> 96 threads in >>>> the test, or so. That's a Linux-2.6.12 and MySQL 5.0.22, so it >>>> should be quite unoptimized >>>> compared to any recent version of anything. >>>> As it seems, you were right. These adjustments made a very slight >>>> performance boost, around >>>> 5%. But it's still lagging behind. >>>> Again, this is MyISAM, not innodb. The "tc4" and "tc16" strings mean >>>> the thread_concurrency >>>> is either set to 4 or 16. Your config had 16, but I've googled for >>>> it, and some resources >>>> suggested setting that to CPUs*2, and that's 4 in my case. >>>> I've updated the MySQL version on FreeBSD to 5.0.51, and will try to >>>> get this version >>>> on linux also, and do a comparision with that one, too. >>>> Sincerely, >>>> Gergely Czuczy >>>> mailto: gergely.czuczy@harmless.hu >>> OK. The caching problem with myisam is unrelated to the other config >>> changes then. >> >> I have to finish my test, sorry for not being able to give more results. >> The boss decided to put back this box to the serverfarm, and since we're >> not using FreeBSD, just I'm a bsd-guy, I won't be able to do anything >> farther >> on on this topic. >> >> I hope I did something useful with this tests of my at all. >> >> And thank you all for helping with all the ideas, especially to >> you, Kris. > > Thanks for bringing it up. If anyone else is interested it would be > good to figure out if there is a way to improve the myisam caching > behaviour. It is likely that performance will also improve once the > lockmgr changes are completed. > > Kris > Hi Kris, We are currently working one a testing various versions of MySQL. I may be able to put you in touch with the guy in charge of the project (on Monday) and see if there is anything he can bring to the table. Tom