The FreeBSD zookeepers politely request that visitors not feed the trolls.
-Kip
On 7/4/06, Danial Thom <[EMAIL PROTECTED]> wrote:
--- Hugo Silva <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]:/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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
