MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
Kip Macy
kip.macy at gmail.com
Wed Jul 5 03:02:20 UTC 2006
The FreeBSD zookeepers politely request that visitors not feed the trolls.
-Kip
On 7/4/06, Danial Thom <danial_thom at yahoo.com> wrote:
>
>
> --- Hugo Silva <hugo at barafranca.com> 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
> >
> > Run #2
> > connect: max=3ms min=1ms avg= 2ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 20253.53
> >
> > Run #3
> > connect: max=4ms min=2ms avg= 2ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 20270.33
> >
> >
> >
> >
> > === 4BSD + libthr + HTT off ===
> >
> > Run #1
> > connect: max=5ms min=2ms avg= 3ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 18253.60
> >
> > Run #2
> > connect: max=6ms min=1ms avg= 3ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 18350.27
> >
> > Run #3
> > connect: max=4ms min=1ms avg= 2ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 18529.71
> >
> >
> > === 4BSD + libpthread + HTT on ===
> >
> > Run #1:
> > connect: max=17ms min=2ms avg= 7ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 5 0
> > 3935.94
> >
> >
> > Run #2:
> > connect: max=18ms min=1ms avg= 8ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 2 0
> > 3919.89
> >
> > Run #3:
> > connect: max=22ms min=1ms avg= 13ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 2 0
> > 3911.66
> >
> >
> > === 4BSD + libpthread + HTT off ===
> > connect: max=12ms min=1ms avg= 5ms from 10
> > clients
> >
> > Run #1:
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 11193.40
> >
> > Run #2:
> > connect: max=6ms min=4ms avg= 5ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 11428.30
> >
> > Run #3:
> > connect: max=7ms min=4ms avg= 5ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 1 0
> > 13714.02
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > === ULE + libthr + HTT on ===
> > Run #1:
> > connect: max=2ms min=0ms avg= 0ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 1 0
> > 16179.09
> >
> > Run #2:
> > connect: max=14ms min=0ms avg= 7ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 17451.31
> >
> > Run #3:
> > connect: max=5ms min=1ms avg= 3ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 1 0
> > 15787.02
> >
> >
> > === ULE + libthr + HTT off ===
> >
> > Run #1:
> > connect: max=6ms min=6ms avg= 6ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 11588.19
> >
> > Run #2:
> > connect: max=220ms min=2ms avg= 46ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time q_per_s
> > select_index 200000 0 0
> > 10651.16
> >
> > Run #3:
> > connect: max=10ms min=0ms avg= 5ms from 10
> > clients
> > Query_type num_queries max_time
> > min_time
> === message truncated ===
>
>
> Instead of wasting your time with BS benchmarks,
> why not write a little script that does actual
> queries that you might be doing on a real, fully
> populated database? And make sure you test with 1
> cpu. I don't see any "scaling" from 1 cpu to 2,
> so I can't get too excited about supersmack's
> miniscule scaling. The only scaling I see going
> from 1 cpu to 2 is about 300 extra dollars for
> the dual-core cpu.
>
> Besides, HTT will slow everything else on the
> system down, so its not practical to turn it on.
> For every benchmark that shows a tiny bit of
> improvement there are 5 that show degradation.
>
> DT
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> freebsd-performance at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to "freebsd-performance-unsubscribe at freebsd.org"
>
More information about the freebsd-performance
mailing list