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 [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
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-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
