On Sun, 7 May 2006, Sven Petai wrote:
I performed tests on a 4 * dualcore 2Ghz opteron system (so 8 cores in
total).
In general with 10 parallel smacker threads the performance seems to go up
with your patch by ~44% and with 100 parallel threads it goes down ~25%
This is an interesting effect I need to explore. Kris reported much increased
contention on locks within the process (between threads) when running with my
patch. It would be interesting to know what the effect on average query time
is -- perhaps it has gone down and we're looking at increased scheduler
related contention.
I noticed the results in the tests seem somewhat variable. I've noticed that
MySQL bennchmarking is heavily affected by test run time and order. It's not
atypical when running a series of identical tests to see a first result half
the end rate, a second result *better* than the end rate, and then it balance
out between the two. For example, I see the following on a dual Xeon:
orangutan# foreach i (`jot 12`)
super-smack /usr/share/smacks/select-key.smack 2 1000 | grep index | awk -F' '
'{print $5}'
end
foreach? super-smack /usr/share/smacks/select-key.smack 2 1000 | grep index |
awk -F' ' '{print $5}'
end
foreach? end
4253.60
8685.55
8324.28
8680.88
8321.53
8391.27
8557.10
8034.79
7532.90
8196.65
7931.77
7981.55
This is quite usual, and is sometimes more pronounced. I'm not surprised the
first run is slower while things get going, binaries are pulled off disk, code
enters the cache, etc. What surprises me is how it bumps up higher
initialially, then goes down to balance at a somewhat lower rate.
Anyhow, what I'm getting at is this: make sure when you measure MySQL
performance, you do a series of runs, discard the first few, and then take an
average of the remainder, and watch out for outliers.
Robert N M Watson
Here's a graph of select smack performance with your patch:
http://bsd.ee/~hadara/debug/mysql4/freebsd_current_06.02.2006_uds_patch/ULE_+_pthread_vs._thr.png
Server crashed before I managed to get enough data to plot graphs
comparing pre-patch and patched performance.
I'll try to generate that and another one, comparing the performance against
linux on the same hardware, tomorrow.
But below you can find some pre and after patch data that should
give some idea of how the patch has impacted performance.
Various test data, benchmarking scripts I used etc. can be found @
http://bsd.ee/~hadara/debug/mysql4/
I have included nice value of mysqld in the tests, because I have found that
the impact of giving mysqld higher priority can have dramatic effects,
especially under 6.X.
This happens probably because super-smack with its 100 procs would
otherwise get scheduling advantage over mysqld with 100 threads.
Hardware:
motherboard: Thunder K8QSD Pro
hdd: scsi seagate cheetah 10K7
ram: 8 * 3200 CL3 kingston ECC 1G
cpu: 4 * opteron 870 (2Ghz dualcore)
Environment:
mysql:
ver: 4.1.18_2 from the ports
table type: MyISAM
config: my-huge.cnf with disabled bin-log and max-connections bumped to 400
database located on a slice mounted with softupdates
super-smack:
ver: from the ports
smacks: default select and update
All tests were run 2 times and mean value was used, unless stated otherwise.
==== FreeBSD current (06.05.2006) ====
scheduler: 4BSD
thr_lib nice queries threads update select
pthread 0 10000 100 3280 8253
pthread 0 100000 10 5037 19972
thr 0 10000 100 4470 20317
thr 0 100000 10 6341 20353
thr -10 10000 100 4457 20530
thr -10 100000 10 6318 21240
scheduler: ULE
thr_lib nice queries threads update select
pthread 0 10000 100 3640 8413
pthread 0 100000 10 5269 21248
thr 0 10000 100 4422 16299*
thr 0 100000 10 6400 22068
thr -10 10000 100 4400 21154
thr -10 100000 10 6211 21877
* - mean over 5 runs since results were rather unstable:
14088.81, 17629.83, 21210.02, 14173.42, 14395.31
==== FreeBSD current (06.05.2006) + uds locking patch ====
scheduler: 4BSD
thr_lib nice queries threads update select
pthread 0 10000 100 3410 8237
pthread 0 100000 10 5150 19786
thr 0 10000 100 4559 14992
thr 0 100000 10 6422 29371
thr -10 10000 100 4535 12589
thr -10 100000 10 6446 30300
scheduler: ULE
thr_lib nice queries threads update select
pthread 0 10000 100 3455 8062
---- lost contact with machine ----
results with various threadcounts at 10000 queries
is available though @
http://bsd.ee/~hadara/debug/mysql4/freebsd_current_06.02.2006_uds_patch/smack_results_ULE.txt
==== FreeBSD 6.1 RC2 ====
scheduler: 4BSD
thr_lib socket nice queries threads update select
pthread unix 0 10000 100 2609 6683
pthread unix 0 100000 10 3752 15052
thr unix 0 10000 100 4802 11496
thr unix 0 100000 10 6398 20738
thr unix -10 10000 100 4607 21066
thr unix -10 100000 10 6379 21411
thr tcp -10 10000 100 4335 9952
scheduler: ULE
thr_lib socket nice queries threads update select
thr unix 0 10000 100 4779 13724
thr unix 0 100000 10 6473 25172
thr unix -10 10000 100 4969 20662
thr unix -10 100000 10 6418 25204
==== Linux ====
suse - suse enterprise linux 9 with kernel 2.6.5-7.97-smp, mysql
4.0.18-32.1, reiserfs
fedora - fedora core with kernel 2.6.9-22-ELsmp, mysql 4.1.12, ext3
distro queries threads update select
suse 10000 100 10047* 76857
fedora 10000 100 8072* 67000
* - on linux the bin-log option was not disabled in the mysql
config, so it would probably have gotten even higher update smack scores
if I had disabled it like I did on freebsd
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
