MySQL 5.6.7-RC in tpcc-mysql benchmark

October 9, 2012
Author
Vadim Tkachenko
Share this Post:

MySQL 5.6.7 RC is there, so I decided to test how it performs in tpcc-mysql workload from both performance and stability standpoints.
I can’t say that my experience was totally flawless, I bumped into two bugs:

 

 

 

But at the end, is not this why RC for? And Oracle asked for a feedback, so I do my part.

 

    • Benchmark date: Oct-2012

 

    • Benchmark goal: Test how MySQL 5.6.7 performs

 

    • Hardware specification
        • Server: Dell PowerEdge R710

       

        • CPU: 2x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz

       

        • Memory: 192GB

       

        • Storage: Very Fast PCIe Flash Card

       

        • Filesystem: ext4

       

       

 

    • Software
        • OS: CentOS 6.3

       

        • MySQL Version: 5.6.7-RC

       

       

 

    • Benchmark specification
        • Benchmark name: tpcc-mysql

       

        • Scale factor: 2500W (~250GB of data)

       

        • Benchmark length: 4000 sec but the result is taken only for last 2000 sec to remove warm-up phase. Measurements are taken every second.

       

       

 

    • Parameters to vary: we vary innodb_buffer_pool_size:13, 25, 50, 75, 100, 125GB to have different memory/data ration. We vary innodb_buffer_pool_instances: 1 and 8, and innodb_log_file_size: 2x4GB and 2x8GB.

Results

The first result is 2x4GB innodb logfiles.

We can see that innodb_buffer_pool_instances=8 makes a big difference on small buffer_pool sizes, while on bigger buffer_pool, innodb_buffer_pool_instances=1 is more preferable.

The the results on big buffer_pool is quite unstable, and the reason is that InnoDB falls into asynchronous flushing mode, the problem which was supposed to be fixed in new InnoDB flushing mechanism. However Dimitry told me that we may need a bigger innodb logfiles to get more stable results.

So there it is with 2x4GB vs 2x8GB innodb logfiles.

Obviously the result is quite better with bigger logs, so size does matter.

Conclusion
innodb_buffer_pool_instances parameter may change the result significantly, especially in intensive IO workloads.
In MySQL 5.6 it is finally possible to achieve stable throughput without dips, but an adaptive flushing still requires big log files.

MySQL configuration:

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments

Far
Enough.

Said no pioneer ever.
MySQL, PostgreSQL, InnoDB, MariaDB, MongoDB and Kubernetes are trademarks for their respective owners.
© 2026 Percona All Rights Reserved