|
List Info
Thread: Array
|
|
| Array |
|
1969-12-31 18:00:00 |
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
q_per_s
select_index 200000 0 0 10158.63
=== ULE + libpthread + HTT on ===
Run #1:
connect: max=9ms min=1ms avg= 7ms from 10 clients
Query_type num_queries max_time min_time
q_per_s
select_index 200000 2 0 5869.52
Run #2:
Query_type num_queries max_time min_time
q_per_s
select_index 200000 2 0 5839.95
Run #3:
Query_type num_queries max_time min_time
q_per_s
select_index 200000 2 0 5680.97
=== ULE + libpthread + HTT off ===
Run #1:
connect: max=10ms min=1ms avg= 8ms from 10 clients
Query_type num_queries max_time min_time
q_per_s
select_index 200000 0 0 6111.21
Run #2:
connect: max=1597ms min=1ms avg= 177ms from 10 clients
Query_type num_queries max_time min_time
q_per_s
select_index 200000 0 0 7225.26
Run #3:
connect: max=9ms min=1ms avg= 4ms from 10 clients
Query_type num_queries max_time min_time
q_per_s
select_index 200000 1 0 8187.13
Conclusions: 4BSD performed much better than ULE.
libthr performs a lot better than libpthread.
I'd risk
saying libpthread has issues!
Hyperthreading is sometimes benefitial. On the
winning
combination (4BSD+libthr), it is benefitial. On some other
combinations
(4BSD+libpthread), it seems to greatly impair performance.
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
| Array |
|
1969-12-31 18:00:00 |
Hugo Silva 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
>
>
Please don't run mysql in PROC_SCOPE with libthr, it has no
benefit and
can only hurt performance, you can forcely turn it off by:
sysctl kern.threads.thr_scope=2
the proc scope support may be dropped near future in libthr,
thanks for
your evaluation.
David Xu
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
| Array |
|
1969-12-31 18:00:00 |
On 07/03/06 14:17 David Xu said the following:
> Please don't run mysql in PROC_SCOPE with libthr, it
has no benefit and
> can only hurt performance, you can forcely turn it off
by:
still, libthr showed oodles better performance than
libpthread. is this
indicative ?
--
Regards, /\_/\ "All dogs
go to heaven."
dineshalphaque.com (0 0) http://www.openmalay
siablog.com/
+==========================----oOO--(_)--OOo----============
==============+
| for a in past present future; do
|
| for b in clients employers associates relatives
neighbours pets; do |
| echo "The opinions here in no way reflect the
opinions of my $a $b." |
| done; done
|
+===========================================================
==============+
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
| Array |
|
1969-12-31 18:00:00 |
Hugo Silva 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
>
>
I think that this, does show impressive scaling to actually
see
performance increase with HTT enabled, from what I have seen
on
benchmarks on many hardware sites testing on MS Windows is
that on the
average best you get is an extra 5% performance out of HTT
per core.
I don't have any quad core machines either, but my dual CPU
Dells that
are around 3.[46]ghz get score of around 25,000
The other promising benchmark I saw on per CPU scaling was a
few months
ago with a posted super smack benchmark on a -current box
that was
getting a score of around 60,000 on a slightly better Quad
core AMD64
machine which proves consistent scaling per core, which as
far as my
memory goes shows good scaling when entering the 4+ core
arena on MySQL.
Mike
>
> === 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
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
| Array |
|
1969-12-31 18:00:00 |
Michael Vince wrote:
>
> Hugo Silva 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
>>
>>
> I think that this, does show impressive scaling to
actually see
> performance increase with HTT enabled, from what I have
seen on
> benchmarks on many hardware sites testing on MS Windows
is that on the
> average best you get is an extra 5% performance out of
HTT per core.
> I don't have any quad core machines either, but my
dual CPU Dells that
> are around 3.[46]ghz get score of around 25,000
>
> The other promising benchmark I saw on per CPU scaling
was a few months
> ago with a posted super smack benchmark on a -current
box that was
> getting a score of around 60,000 on a slightly better
Quad core AMD64
> machine which proves consistent scaling per core, which
as far as my
> memory goes shows good scaling when entering the 4+
core arena on MySQL.
>
> Mike
>
Actually, with proper scheduling behaviour, HTT is usefull,
I saw very high performance boosts when running sysbench :
sysbench --test=oltp --oltp-table-size=1000000
--mysql-host=192.168.82.170 --mysql-user=test
--mysql-db=test
--oltp-read-only --num-threads=256 --max-requests=10000 run
This benchmark runs on my Dual XEON (2.8Ghz, HTT enabled),
when the
scheduler is SCHED_CORE, it only requires 30 seconds, while
a 4bsd
scheduler needs 52 seconds, last time, I wrongly wiped some
code in
SCHED_CORE (which is now in tree), performance is degraded.
I need some time to make the scheduler works properly.
David Xu
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
| Array |
|
1969-12-31 18:00:00 |
David Xu wrote:
> Michael Vince wrote:
>
>>
>> Hugo Silva 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
>>>
>>>
>> I think that this, does show impressive scaling to
actually see
>> performance increase with HTT enabled, from what I
have seen on
>> benchmarks on many hardware sites testing on MS
Windows is that on
>> the average best you get is an extra 5% performance
out of HTT per core.
>> I don't have any quad core machines either, but my
dual CPU Dells
>> that are around 3.[46]ghz get score of around
25,000
>>
>> The other promising benchmark I saw on per CPU
scaling was a few
>> months ago with a posted super smack benchmark on a
-current box that
>> was getting a score of around 60,000 on a slightly
better Quad core
>> AMD64 machine which proves consistent scaling per
core, which as far
>> as my memory goes shows good scaling when entering
the 4+ core arena
>> on MySQL.
>>
>> Mike
>>
>
> Actually, with proper scheduling behaviour, HTT is
usefull,
> I saw very high performance boosts when running
sysbench :
>
> sysbench --test=oltp --oltp-table-size=1000000
> --mysql-host=192.168.82.170 --mysql-user=test
--mysql-db=test
> --oltp-read-only --num-threads=256 --max-requests=10000
run
>
> This benchmark runs on my Dual XEON (2.8Ghz, HTT
enabled), when the
> scheduler is SCHED_CORE, it only requires 30 seconds,
while a 4bsd
> scheduler needs 52 seconds, last time, I wrongly wiped
some code in
> SCHED_CORE (which is now in tree), performance is
degraded.
> I need some time to make the scheduler works properly.
>
> David Xu
That sounds very promising.
Also note when I said 5% performance improvement as average
best I was
referring to real world benchmark tests that you see
typically on
Anandtech and so on, maybe this rule of thumb has changed
over time, (I
remember reading as Anands view on HTT at one time in the
past)
I have tended to see (and also read it so ) that HTT is
largely just a
5% real world freebie that Intel created to get software
developers
thinking MP so when the real dual and eventually quad cores
were
released, there would be some software for mainstream
consumers to
benefit from, ready to take advantage of their new CPUs.
Its probably hard for Intel to forget that it took MS 10
years since the
release of the i386 chip to release a mass consumer almost
purely 32bit
OS that being Windows 2000 and XP (don't argue NT4 was for
the average
home user).
HTT was Intels best early stab to help path the way for
their multi core
technologies to come into use as quickly as possible for the
masses over
just the server end.
Mike
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
| Array |
|
1969-12-31 18:00:00 |
Michael Vince wrote:
> HTT was Intels best early stab to help path the way for
their multi
> core technologies to come into use as quickly as
possible for the
> masses over just the server end.
Exactly, thats why i wouldn't spend too much time bothering
with HTT. It
was a transitional technology for multi core CPUs, which are
now the
standard. It will be interesting how the new Conroe
processors fair on
FreeBSD, the early benchmarks show better performance than
AMDs offerings.
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
| MySQL 5.0.22 , FreeBSD 6.1-STABLE:
Benchmark |
|
2006-07-05 01:20:46 |
--- Hugo Silva <hugobarafranca.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-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
| MySQL 5.0.22 , FreeBSD 6.1-STABLE:
Benchmark |
|
2006-07-05 03:02:17 |
The FreeBSD zookeepers politely request that visitors not
feed the trolls.
-Kip
On 7/4/06, Danial Thom <danial_thomyahoo.com> wrote:
>
>
> --- Hugo Silva <hugobarafranca.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-performancefreebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
> To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
>
_______________________________________________
freebsd-performancefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-p
erformance
To unsubscribe, send any mail to
"freebsd-performance-unsubscribefreebsd.org"
|
|
[1-9]
|
|