Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
- From: Danial Thom <danial_thom@xxxxxxxxx>
- Date: Tue, 4 Jul 2006 18:20:46 -0700 (PDT)
--- Hugo Silva <hugo@xxxxxxxxxxxxxx> wrote:
Today I decided to benchmark MySQL 5=== message truncated ===
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
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
- From: Kip Macy
- Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
- References:
- MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
- From: Hugo Silva
- MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
- Prev by Date: Re: Updated fine-grain locking patch for UNIX domain sockets
- Next by Date: Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
- Previous by thread: Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
- Next by thread: Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark
- Index(es):
Relevant Pages
|
|