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