From owner-freebsd-performance@FreeBSD.ORG Mon Jul 3 10:04:49 2006 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CEB3016A403; Mon, 3 Jul 2006 10:04:46 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <44A8EBC0.5090805@freebsd.org> Date: Mon, 03 Jul 2006 18:04:48 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060519 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Vince References: <44A894B0.3010506@barafranca.com> <44A8D270.1080009@thebeastie.org> In-Reply-To: <44A8D270.1080009@thebeastie.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 10:04:49 -0000 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