From owner-freebsd-performance@FreeBSD.ORG Wed Apr 5 14:26:07 2006 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0242816A401 for ; Wed, 5 Apr 2006 14:26:07 +0000 (UTC) (envelope-from hadara@bsd.ee) Received: from mail.neti.ee (smtp-out-1.neti.ee [194.126.101.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3935D43D45 for ; Wed, 5 Apr 2006 14:26:05 +0000 (GMT) (envelope-from hadara@bsd.ee) Received: from nat-155.nat (test.estpak.ee [194.126.115.47]) by Relayhost2.neti.ee (Postfix) with ESMTP id 47F9B14063 for ; Wed, 5 Apr 2006 17:25:58 +0300 (EEST) From: Sven Petai To: freebsd-performance@freebsd.org Date: Wed, 5 Apr 2006 17:30:51 +0300 User-Agent: KMail/1.9.1 References: <200604041942.18767.hadara@bsd.ee> <200604051331.23826.yfxu@corp.netease.com> In-Reply-To: <200604051331.23826.yfxu@corp.netease.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604051730.52014.hadara@bsd.ee> X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee Subject: Re: mysql performance on 4 * dualcore opteron 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, 05 Apr 2006 14:26:07 -0000 On Wednesday 05 April 2006 08:31, David Xu wrote: > > Can you disable log-bin option in my.cnf to see if it is a FS bottleneck > when you are running update-smack ? please run Linux and FreeBSD > with same hardware and my.cnf configuration, thanks. > I know this is not very right, but it can be used to narrow down some > kernel performance problem. I can't test disabling log-bin option right now since those 8 core systems were shipped out to client today, but I will probably get access to some identical servers next week, so I will then test this and whatever other suggestions you people can come up with. Until then can we maybe consentrate on * why does 8 core machine get so awful select score without renicing mysqld * why is select result on linux >65000 q/s while fbsd can do only about 21000 q/s But the bencmark results that I stated for 8 core machines were done on 4 _identical_ servers, with following operating system installations: server 1 - suse enterprise linux 9 with kernel 2.6.5-7.97-smp, mysql 4.0.18-32.1, reiserfs server 2 - Fedora core with kernel 2.6.9-22-ELsmp, mysql 4.1.12, ext3 server 3 & server 4 - freebsd 6.1 beta 4,generic-smp kernel, mysql 4.1.12_2 from ports, ufs2 + softupdates, libthr While it was not the very _same_ hardware, the machines were absolutelly identical in every aspect and fbsd results on 2 servers were identical within the limits of measurement error so it's rather unlikely that some hardware glitch can be blamed for the differences. The mysql configuration file was also identical - default my-huge.cnf with max_connections change @ http://bsd.ee/~hadara/debug/mysql3/2way/my.cnf Hardware spec of those servers was: motherboard: Thunder K8QSD Pro hdd: scsi seagate cheetah 10K7 ram: 8 * 3200 CL3 kingston ECC 1G cpu: 4 * opteron 870 (2Ghz dualcore) Results for other UP and dual machines that I mentioned were given just to give some general feeling about scalability. So just to state the 8 core results in a more concise manner: smack suse fedora fbsd 6.1b4 ----------------------------------------------------- select 76857 67000 21000 update 10047 8072 4100