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 _at_ > 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 _at_ > 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 > >Received on Sun May 07 2006 - 16:16:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:55 UTC
