One of the goals we had originally with the MySQL 5.4
development was to improve scaling from 4 cores to
8 cores. So in my early testing I ran comparisons of
the Google SMP + IO + tcmalloc patches on 4, 8 and 12
cores to see how it behaved compared with a stock
MySQL 5.1.28 version (Note the comparison here was
done on a very early version of 5.4, 5.4.0 have a
set of additional patches applied to it).



What we can see here is that the Google SMP patch and use
of tcmalloc makes a difference already on a 4-core server
using 4 threads. On 1 and 2 threads the difference is only
on the order of 1-2% so not really of smaller significance.

An interesting note in the graph is that 8-core numbers using
the Google …

Last week we were busy to align XtraDB performance with 5.4, now we have some results. Currently it is available as "hacks" to XtraDB (available on Lauchpad lp:~percona-dev/percona-xtradb/hacks-porting-tune if you are interested). Basically we took improvements from 5.4 and backported ones performance related to XtraDB.

Here are results for tpcc-like workload, 100W (~10GB) ( raw results and parameters are available here
http://spreadsheets.google.com/ccc?key=rxUEhM2dqbX0uAfq9j6WQ_w ). Box Dell PowerEdge R900 (Does Dell have referral program ? ), with RAID10 (8 disks) on ext3, 32GB of RAM.

As you see there almost no difference and you may say what's the reason in XtraDB ? The most interesting reason is XtraDB based on InnoDB-plugin and contains its nice features like FAST INDEX CREATION and dynamic pages. And XtraDB has some …

In benchmarks passion (see my two previous posts) I managed to setup all three devices (RAID was on board; Intel X25-E SSD connected to HighPoint controller, FusionIO card) on our working horse Dell PowerEdge R900 (btw, to do that I had to switch from CentOS 5.2 to Ubuntu 8.10, as CentOS was not able to start with attached SSD card to HighPoint controller) and along with other tests I ran tpcc-like IO-bound workload on all devices.

For tests I used MySQL 5.4/InnoDB, and all other parameters are the same from previous posts (100W, buffer_pool 3GB). Filesystem - XFS mounted with nobarrier option.

Graphical results are here

and average results:

RAID10 - 7439.850 TPM
SSD - 10681.050 TPM
FusionIO - 17372.250 TPM

However what should be noted - both SSD and FusionIO are run in "non-durable" mode, that is you may lose some transactions in …

As continue to my benchmarks http://www.mysqlperformanceblog.com/2009/04/30/looking-on-54-io-bound-benchmarks/ on 5.4 I tried in-memory load (basically changed buffer pool from 3GB to 15GB, and database size is 10GB). The results are on the same spreadsheet http://spreadsheets.google.com/ccc?key=rYZB2dd2j1pQsvWs2kFvTsg&hl=en#, page CPUBound.

I especially made short warmup (120 sec) and long run (2700sec) to see how different versions go through warmup stage.

The graph is

In default mode I would say XtraDB performs almost the same as 5.4, but dips are a bit worse than in 5.4.

Now about dips - all of them are caused by InnoDB checkpoint activity, InnoDB is doing intensive flushing of …

With a lot of talks around 5.4 I decided to check how it works in our benchmarks. For first shoot I took tpcc-like IO-bound benchmark (100W, ~10GB of data, 3GB buffer_pool) and tested it on our Dell PowerEdge R900 box (16 cores, 32GB of RAM, RAID 10 on 8 SAS 2.5" 15K RPM disks). For comparison I took XtraDB-release5 and 5.0.77-highperf percona release.

For raw results you can check my Google Spreadsheet (it is also being update with my next CPU benchmarks, and benchmark on SSD & FusionIO), also I post graph there:

Results are in TPM (transactions per minute, more is better).

So I can confirm that MySQL team did great job with 5.4 and it shows the best results.
Some more results you can find on Dimitri's blog, one of Sun Performance Engineers.

…

If you like to sift through tons of benchmark data about various
MySQL versions, Dimitri at the Sun Benchmark Labs have published
a serious amount of benchmark data in a report published here.

The report shows that the new MySQL 5.4.0 release
have a very good performance. The report also shows how the day
of a developer of performance improvements and the massive amount
of benchmark data that needs to be analysed and sifted through
to understand the impact of new performance improvements.

I personally met Dimitri the first time in 2002 when I was working
together with him for a couple of weeks on a benchmark on NDB Cluster
(the storage engine of MySQL Cluster). Our goal then was to perform
1 million reads per second on a 72-cpu SPARC box with …

In InnoDB there is an implementation of both mutexes
and RW-locks. The RW-locks implementation have been
improved by the Google SMP patches. Both of these
implementation relies on spin-loops as part of their
implementation. The defaults in InnoDB is to check
the condition, if it's not ok to enter to spin for
about 5 microseconds and then come back to check the
condition again.

If one reads the Intel manual how to do spin-loops
they propose to use a PAUSE instruction and then
check the condition again, so a much more active
checking of the condition. When we tried this out
using the sysbench benchmark we found that using
the Intel approach worsened performance. So instead
we tried an approach of putting the PAUSE instruction
into the InnoDB spinloop instead.

This approach turned out to be a success. Even on
machines with only one …

One of the things we've been working on in Drizzle is having automated performance regressions run when we push new code. Although the fully automated system isn't quite there yet, one of the pieces is, which is a Drizzle-supporting version of sysbench.

I've pushed the code to:

 lp:~drizzle-developers/sysbench/trunk

This new version of sysbench has a libdrizzle driver which can be used to run benchmarks against Drizzle, or, since libdrizzle can also talk to MySQL, to MySQL.

Getting started playing with it is pretty easy, just make sure you've installed a recent copy of libdrizzle first.

  bzr init-repo sysbench

  cd sysbench

  bzr branch  lp:~drizzle-developers/sysbench/trunk

  cd trunk

   ./autogen.sh

  ./configure

  make

  make install

From that point, you should be able …

One of the things we've been working on in Drizzle is having automated performance regressions run when we push new code. Although the fully automated system isn't quite there yet, one of the pieces is, which is a Drizzle-supporting version of sysbench.

I've pushed the code to:

 lp:~drizzle-developers/sysbench/trunk

This new version of sysbench has a libdrizzle driver which can be used to run benchmarks against Drizzle, or, since libdrizzle can also talk to MySQL, to MySQL.

Getting started playing with it is pretty easy, just make sure you've installed a recent copy of libdrizzle first.

  bzr init-repo sysbench

  cd sysbench

  bzr branch  lp:~drizzle-developers/sysbench/trunk

  cd trunk

   ./autogen.sh

  ./configure

  make

  make install

From that point, you should be able …