Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Nov 2004 20:22:08 +0800
From:      Ganbold <ganbold@micom.mng.net>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        jhopper@bsdhosting.net
Subject:   Re: [Fwd: Re: Mysql - Linuxthreads : Still needed?]
Message-ID:  <6.2.0.14.2.20041115200900.0301a9b0@202.179.0.80>
In-Reply-To: <Pine.NEB.3.96L.1041115105150.66223H-100000@fledge.watson.o rg>
References:  <4192763C.2010403@elischer.org> <Pine.NEB.3.96L.1041115105150.66223H-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Some mysql benchmark I just did...

-----------------------------------------------------------------------
System Specs:

IBM @server 325 type 8835
Dual AMD Opteron 2.1ghz
4GB (2x2GB) PC-2700 ECC memory
6x36GB hot swap RAID5 Ultra 320 SCSI HDD
ServeRAID 6M controller

-------------------------------------------------------------------------
OS / Software Configuration:

FreeBSD amd.micom.mng.net 5.3-STABLE FreeBSD 5.3-STABLE #6: Thu Nov 11 
21:08:50 ULAT 2004     tsgan@amd.micom.mng.net:/usr/obj/usr/src/sys/AMD  amd64

MySQL Compiled from mysql40-server port with:

BUILD_OPTIMIZED=yes
BUILD_STATIC=yes

-------------------------------------------------------------------------
kernel without SMP and without PREEMPTION options
-------------------------------------------------------------------------
amd# cat test_nosmp_nopreemption
Query Barrel Report for client smacker
connect: max=7ms  min=2ms avg= 4ms from 30 clients
Query_type      num_queries     max_time        min_time        q_per_s
select_index    300000  4       0       3565.71
update_index    300000  4       0       3565.71
-------------------------------------------------------------------------

-------------------------------------------------------------------------
kernel without SMP and with PREEMPTION options
-------------------------------------------------------------------------
amd# cat test_nosmp_preemption
Query Barrel Report for client smacker
connect: max=18ms  min=1ms avg= 8ms from 30 clients
Query_type      num_queries     max_time        min_time        q_per_s
select_index    300000  6       0       3568.64
update_index    300000  4       0       3568.64
-------------------------------------------------------------------------

-------------------------------------------------------------------------
kernel with SMP and without PREEMPTION options
-------------------------------------------------------------------------
amd# cat test_smp_nopreemption
Query Barrel Report for client smacker
connect: max=16ms  min=5ms avg= 8ms from 30 clients
Query_type      num_queries     max_time        min_time        q_per_s
select_index    300000  4       0       3755.09
update_index    300000  3       0       3755.09
-------------------------------------------------------------------------

-------------------------------------------------------------------------
kernel with SMP and with PREEMPTION options
-------------------------------------------------------------------------
amd# cat test_smp_preemption
Query Barrel Report for client smacker
connect: max=14ms  min=9ms avg= 10ms from 30 clients
Query_type      num_queries     max_time        min_time        q_per_s
select_index    300000  4       0       4053.86
update_index    300000  3       0       4053.86
-------------------------------------------------------------------------

It seems like fastest result I get in kernel with SMP and with PREEMPTION 
options.

regards,

Ganbold


At 06:56 PM 11/15/2004, you wrote:

>On Wed, 10 Nov 2004, Julian Elischer wrote:
>
> > send to the right list.
>
>So, the good news is that we've successfully dramatically improved the
>performance of MySQL between 5.2 and 5.3.  The mixed news is that clearly
>we have more work to do. :-)  Out of curiousity, has anyone done much in
>the way of kernel profiling during heavy duty MySQL runs to see if there
>are specific kernel bottlenecks we can be working on?
>
>I've noticed that we're contending a fair amount on UNIX domain socket
>locking, although with Giant off the stack this is a big improvement over
>what we saw previously.  Although it was a few months ago, my recollection
>from profiling the mutex use and kernel use is that we're spending a lot
>of time checking to see if we have to deliver signals to threads or not in
>kernel.  I may have the opportunity to do a bit of profiling today or
>tomorrow and see what I bump into.
>
>Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
>robert@fledge.watson.org      Principal Research Scientist, McAfee Research
>
>
>_______________________________________________
>freebsd-threads@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-threads
>To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.0.14.2.20041115200900.0301a9b0>