hi 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% 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 freebsdReceived on Sun May 07 2006 - 14:50:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:55 UTC
