Re-running the same tests that I had done before to generate the graphs really does tell a picture, even when just looking at the thumbnail view:

InnoDB INSERT no atomicsInnoDB INSERT atomics

The timings may not be a true reflection of the consistent overhead (this is my macbook, which does a lot of other work whilst I’m testing this stuff out), but just looking at the difference in numbers of synchronization points, it’s clear that there will be far less contention (and hence potential wait time) in the atomics cases – obviously.

So what’s the lesson we can learn from this?

If you see a large number of waits for either the wait/synch/mutex/innodb/rw_lock_mutex or wait/synch/mutex/innodb/thr_local_mutex, you may want to investigate whether the build you are using for your platform has atomic operations enabled. If not, then consider finding a platform or build that does support them.

These are instrumented within performance_schema within the current 5.5 GA release as well, so you can tell whether these are one of your top waits by simply looking at the summary of all mutex waits for InnoDB globally:

This is a standard MySQL 5.5.10 build for OS X, which has had similar kinds of statements run against it. We can see that wait/synch/mutex/innodb/rw_lock_mutex has had 0 waits, and wait/synch/mutex/innodb/thr_local_mutex has only had 11 waits globally. None are anywhere near close to the top wait events. This build most certainly does have atomics enabled.

5 thoughts on “What a difference Atomics can make”

@DaniÃ«l van Eeden I know, this was done for a reason however – as the buffers that performance_schema uses to store the instrumentation data are a fixed size (ring buffers), so that we don’t cause (expensive) memory allocation for instrumentation inside of the statements that we are tracking.

Well, that instrumentation is certainly not for free (although it is relatively light overhead – and 5.6 has made even more headway here). I believe that was why it was chosen to not be enabled by default however.

I’d love to see it on by default. But first we want/need people trying it, getting happy with it etc. – and then telling us to enable it by default. 😉