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 …

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 …

So a while ago I wrote about fun post about MySQL Scalability to 256 way....

Besides discussion on the thread itself I had a lot of private comments in my mail from Sun/MySQL employees which tended to agree with me on this being the a large stretch.

I would hope Sun/MySQL would tone it down and actually spend time on making things to scale inside MySQL rather than asking you to run tens of MySQL instances to get reasonable performance, but sure enough writing code is harder than writing marketing materials so this work now made it to the Sun blueprint making it recommended reference architecture.

It is also interesting to go back to my old post about …

Playing with last version of xtrabackup and compress it I noticed that gzip is unacceptable slow for both compression and decompression operations. Actually Peter wrote about it some time ago, but I wanted to review that data having some new information. In current multi-core word the compression utility should utilize several CPU to speedup operation, and another my requirement was the ability to work with stdin / stdout, so I could do scripting something like: innobackupex --stream | compressor | network_copy.

My research gave me next list: pigz (parallel gzip), …

Introduction
When people think about Percona’s microslow patch immediately a question arises how much logging impacts on performance. When we do performance audit often we log every query to find not only slow queries. A query may take less than a second to execute, but a huge number of such queries may significantly load a server. On one hand logging causes sequential writes which can’t impair performance much, on other hand when every query is logged there is a plenty of write operations and obviously performance suffers. Let’s investigate how much.

I took DBT2, an OSDL’s implementation of TPC-C.
Hardware used
The benchmark was run on a DELL server running CentOS release 4.7 (Final)
There are four CPUs Intel(R) Xeon(R) CPU 5150 @ …

In many cases I speculate how things should work based on what they do and in number of cases this lead me forming too good impression about technology and when running in completely unanticipated bug or performance bottleneck. This is exactly the case with LVM

Number of customers have reported the LVM gives very high penalty when snapshots are enabled (leave along if you try to run backup at this time) and so I decided to look into it.

I used sysbench fileio test as our concern is general IO performance in this case - it is not something MySQL related.

I tested things on RHEL5, RAID10 volume with 6 hard drives (BBU disabled) though the problem can be seen on variety of other systems too (I just do not have all comparable numbers)

O_DIRECT RUN

PLAIN TEXT CODE:

So I saw the tokutek challenge, and wondered to myself how Maria would get along with it. I duly downloaded a 6.0 tree, and the iiBench code, tinkered with it to make it actually build, and fired things up.

I watched it closely, for about a day, then got bored and forgot about it. I remembered today that I should take a look!

CPU Usage (Quad Core)

Average rows per second inserted

Load Averages

You can …

I mentioned earlier that IO scheduler CFQ coming by default in RedHat / CentOS 5.x may be not so good for MySQL. And yesterday one customer reported that just changing cfq to noop solved their InnoDB IO problems. I ran tpcc scripts against XtraDB on our Dell PowerEdge R900 server (16 cores, 8 disks in RAID10, controller Perc/6i with BBU) to compare cfq, deadline, noop and anticipatory (last one just to get number, I did not expect a lot from anticipatory).

Here is result (in transactions per minute, more is better):

…