When I worked with Dimitri on the analysis of the
Split Rollback Segment Mutex he came up with numbers
on InnoDB Thread Concurrency set to 16 and 32 and I was
curious
to see if 24 was the optimal setting. So he made some new runs
and
some new graphs that I found interesting.

The first graph analyses behaviour of MySQL 5.4.0 on a
SPARC
Server using InnoDB Thread Concurrency set to 0, 16, 24 and
32.
Interestingly for both readonly and readwrite benchmarks
the
optimal setting for concurrency is 16 whereas the top
numbers …

Here is the performance graph comparing using
InnoDB Thread Concurrency equal to 0 and
InnoDB Thread Concurrency equal to 24 using
sysbench readwrite with the new InnoDB
Thread concurrency algorithm as introduced
in MySQL 5.4.0.

When benchmarking MySQL with InnoDB we quickly discovered
that using InnoDB Thread Concurrency set to 0 was an
improvement to performance since the implementation of
InnoDB Thread Concurrency used a mutex which in itself was
a scalability bottleneck.

Given that InnoDB Thread Concurrency is a nice feature that
ensures that one gets good performance also on an
overloaded
server I was hoping to find a way to make the
implementation
of this more scalable.

I tried out many different techniques using a combination
of
mutexes and atomic variables. However every technique fell …

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.