From owner-freebsd-performance@FreeBSD.ORG Mon Jul 3 15:20:46 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 A6BBE16A407; Mon, 3 Jul 2006 15:20:46 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id D382443D6B; Mon, 3 Jul 2006 15:20:39 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id D1DF04CED9; Mon, 3 Jul 2006 15:20:50 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 21B2D4CED4; Mon, 3 Jul 2006 15:20:50 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id C839B8A031; Tue, 4 Jul 2006 01:20:36 +1000 (EST) Received: from [192.168.0.6] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id 7405E8A029; Tue, 4 Jul 2006 01:20:36 +1000 (EST) Message-ID: <44A935C7.3070605@thebeastie.org> Date: Tue, 04 Jul 2006 01:20:39 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20060526 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <44A894B0.3010506@barafranca.com> <44A8D270.1080009@thebeastie.org> <44A8EBC0.5090805@freebsd.org> In-Reply-To: <44A8EBC0.5090805@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-performance@freebsd.org, Hugo Silva Subject: Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark 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: Mon, 03 Jul 2006 15:20:46 -0000 David Xu wrote: > Michael Vince wrote: > >> >> Hugo Silva wrote: >> >>> Today I decided to benchmark MySQL 5 performance on FreeBSD 6.1-STABLE. >>> This server is a Dual Xeon 2.8GHz, 4GB of RAM and 2x73GB SCSI disks >>> that do 320MB/s >>> >>> For all the tests, I restarted mysqld prior to starting the test, >>> waited for about 1 minute for it to settle down, and ran super >>> smack. For the consecutive runs, I executed super-smack right after >>> the previous run ended. >>> >>> Switching from HTT to no HTT was achieved by >>> machdep.hyperthreading_allowed, and switching from/to >>> libpthread/libthr was done via libmap.conf. >>> >>> System: >>> >>> FreeBSD ?? 6.1-STABLE FreeBSD 6.1-STABLE #3: Mon Jul 3 03:10:35 UTC >>> 2006 ??@??:/usr/obj/usr/src/sys/DATABASE i386 >>> >>> Here are the results: >>> >>> >>> MySQL 5.0.22, built with BUILD_OPTIMIZED=yes and >>> WITH_PROC_SCOPE_PTH=yes >>> >>> >>> === 4BSD + libthr + HTT on === >>> >>> Run #1 >>> connect: max=4ms min=1ms avg= 3ms from 10 clients >>> Query_type num_queries max_time min_time q_per_s >>> select_index 200000 0 0 20405.86 >>> >>> >> I think that this, does show impressive scaling to actually see >> performance increase with HTT enabled, from what I have seen on >> benchmarks on many hardware sites testing on MS Windows is that on >> the average best you get is an extra 5% performance out of HTT per core. >> I don't have any quad core machines either, but my dual CPU Dells >> that are around 3.[46]ghz get score of around 25,000 >> >> The other promising benchmark I saw on per CPU scaling was a few >> months ago with a posted super smack benchmark on a -current box that >> was getting a score of around 60,000 on a slightly better Quad core >> AMD64 machine which proves consistent scaling per core, which as far >> as my memory goes shows good scaling when entering the 4+ core arena >> on MySQL. >> >> Mike >> > > Actually, with proper scheduling behaviour, HTT is usefull, > I saw very high performance boosts when running sysbench : > > sysbench --test=oltp --oltp-table-size=1000000 > --mysql-host=192.168.82.170 --mysql-user=test --mysql-db=test > --oltp-read-only --num-threads=256 --max-requests=10000 run > > This benchmark runs on my Dual XEON (2.8Ghz, HTT enabled), when the > scheduler is SCHED_CORE, it only requires 30 seconds, while a 4bsd > scheduler needs 52 seconds, last time, I wrongly wiped some code in > SCHED_CORE (which is now in tree), performance is degraded. > I need some time to make the scheduler works properly. > > David Xu That sounds very promising. Also note when I said 5% performance improvement as average best I was referring to real world benchmark tests that you see typically on Anandtech and so on, maybe this rule of thumb has changed over time, (I remember reading as Anands view on HTT at one time in the past) I have tended to see (and also read it so ) that HTT is largely just a 5% real world freebie that Intel created to get software developers thinking MP so when the real dual and eventually quad cores were released, there would be some software for mainstream consumers to benefit from, ready to take advantage of their new CPUs. Its probably hard for Intel to forget that it took MS 10 years since the release of the i386 chip to release a mass consumer almost purely 32bit OS that being Windows 2000 and XP (don't argue NT4 was for the average home user). HTT was Intels best early stab to help path the way for their multi core technologies to come into use as quickly as possible for the masses over just the server end. Mike