Created: 2008-12-18
Last modified: 2009-01-29

MySQL Performance: PERCONA

by Dimitri

SSC Team, 2008
Sun Microsystems Inc.

Ces informations sont données à titre indicatif et n'engagent pas Sun Microsystems.

Table of contents

Benchmark Information
Customer Name(s): MySQL

Contact Information:

Dates: Dec.2008 - Jan.2009

Keywords: MySQL, InnoDB, Percona, XtraDB, db_STRESS

Hardware Configuration
     - M5000 8CPU SPARC64-VIII 2400Mhz quad-core bi-thread, 64GB RAM
     - M8000 16CPU SPARC64-VI 2200Mhz bi-core bi-thread, 256GB RAM

     - ST6140 2x LUNs (RAID1 1TB each), 2Gb Fiber Channel connection

Software Configuration
     - Solaris 10 Update 6
     - UFS

     - MySQL
     - db_STRESS

Overview: During the last performance study I was very curious to understand what was wrong with MySQL Percona patched build. Due limited time I did not get a 64bit version compiled and supposed it was the main problem... Well, now I have a powerful enough M5000 server in my hands and will try to see more closely what's happens.

Goal(s): Reach the best possible performance level with MySQL Percona build

Result(s): All details are in report :-))

Initial Test

db_STRESS test scenarios will be still the same (for details get a look at

On the same time while I've prepared my test platform, there was MySQL Percona build-10 ready for download!

Percona specific tuning
Percona build has a list of additional options (a very good presentation you may find here:

I've tried to see the difference by add the following ones:

# Percona
innodb_io_capacity = 10000
innodb_adaptive_checkpoint = 1
innodb_write_io_threads = 16
innodb_read_io_threads = 16

XtraDB Engine
On the same time I've prepared these tests, Persona announced their "XtraDB" engine:

Should I say I was curious to see it in action? :-))

I've downloaded the sources and folowing REDME instructions compiled it within MySQL v.5.1.30 as part of mysqld.

Current points:

Stay tuned! More to come! :-)

Additional Tests

Discussing with Percona team, we were able to replay the same tests on their Linux server (RedHat, 8cores Xeon). And I was really surprised to hear they obtaining the same performance level on XtraDB as on InnoDB-plugin... Comparing our plateforms, the only significant difference I've found (on my point of view) is a number of CPU/cores (I don't think there is some significant difference between Linux and Solaris for MySQL, as well we're not comparing server results, but performance gap between XtraDB and InnoDB)... Well, to be completely honest I was surprised anyway to see they got on Xeon 6.000 TPS during Read+Write workload comparing to my 4.000 on SPARC64 :-))

Anyway, I supposed the key point here is the number of cores - all applications having scalability problems due locks will have their "critical limit" after which performance level will only decrease... And on my opinion they should try the same test on 16 core server (but they don't have it)... And finally the only way to verify my suppositions is to replay my tests on my platform but with 8 cores too :-))

And here are my results...

Investigating InnoDB internals...
In parallel I've finally finished to write a wrapper analyzing and reformatting InnoDB status output! Analyzing data from InnoDB internals during my tests I understood I still did not understand everything until no :-))

So, adventure continues... :-))