Hi Axel, it looks like locking profile of thr locks in read-write load is more complex. Probably fast mutex behaves better in this scenario. OTOH table cache lock durations do not depend on load type. Could you benchmark it again with the following patches (attached): 1. unpatched 2. with thr lock patched 3. with table cache lock patched 4. with thr and table cache locks patched ...so we could pick best combination. Thanks, Sergey On Mon, Mar 03, 2014 at 09:37:01AM +0100, Axel Schwenke wrote:
Moin Svoj,
Sergey Vojtovich wrote:
Sergei pointed out that there is up to 10% slowdown in read-write benchmark at high concurrency. Could you share benchmark details, I'd like to debug it. Just pointers to build/run scripts on the benchmark server should be enough.
The benchmark was run on lizard2. Build script is ~/bin/xl_build_new
Benchmark runs under ~/benchmark/sysbench
series46 ... ro, single table, PFS=on, 32-128 threads series47 ... ro, single table, PFS=off, 32-128 threads series48 ... ro, multi table, PFS=on, 32-128 threads series49 ... ro, multi table, PFS=off, 32-128 threads series50 ... rw, multi table, PFS=off, 1-512 threads
HTH, XL