Fine-grained locking for POSIX local sockets (UNIX domain
sockets)
Robert Watson
rwatson at FreeBSD.org
Sun May 7 18:16:44 UTC 2006
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
>
>
More information about the freebsd-performance
mailing list