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>