Only a little over a week before the User conference and I am still burning the midnight oil to get as much information for my presentations as possible. I thought I would tease you a bit here. What do you get when you put 4 Intel X-25E’s ( Sun branded) SSD’s running RAID10 in a Sun 4450 and run the sysbench fileio test on it?

I am doing the final prep work for my upcoming UC presentation on SSD’s, and I thought I would throw this out their. Recently their has been a great deal of discussion on the write cache on the Intel x-25e and whether you need to disable it to prevent data loss on a power outage. Most disk caches are not protected by a battery backup and are disabled by default on most high end controllers. Who wants to potentially lose 16-64MB of data on an outage? So it seems like it would make sense that you should disable the cache on the Intel drives as well. But their is a problem. Vadim over at the MySQL Performance Blog recently published some benchmarks that show some rather slow results when the disk cache is disabled, in fact I have also noticed a significant slow down in these cases as well. So this leads to the …

Here are some common performance tuning concepts that I frequently run into. Please note that this really is only a basic introduction to performance tuning. For more in-depth tuning, it strongly depends on your systems, data and usage. Server Variables For tuning InnoDB performance, your primary variable is innodb_buffer_pool_size. This is the chunk of memory that InnoDB uses for caching data,

By transparently sitting between client and server on each request, MySQL Proxy offers many possibilities for query manipulation.

Many are explored in the cookbook, and they even include a histogram recipe. Still, I wanted to learn more about the proxy while working on a script that would let me get some stats on the queries executed against a server (or group of servers).

First things first, get a brief glimpse of the lua programming language since that’s what the proxy’s scripts are written in. Alternatively, you can jump straight into the sample scripts, extrapolate what you don’t understand of the syntax by making paralelizations against other …

Yes we are still plugging away working on Waffle Grid, in fact I am testing the heck out of the plugin release this week. Some good news, great news, and bad news to report.

The good news on the testing is using the new Waffle Grid release, I am able to consistently get up close to 15K TPM, that’s up from 3K TPM without WaffleGrid ( 5x increase woohoo! ). This performance boost holds true through several tests, and based on this testing I am working on a set of recommended parameters for getting the most performance out of Waffle. I should have my recommendations for our User Conference presentation.

The great news is I have been able to get close to 20K TPM by disabling the read-ahead! This represents a huge boost in performance, over both the read-ahead enabled and the non-waffle tests. The bad news is in extended tests with the read-ahead disabled the plugin version takes a crap on me and consistently dies about 22-24 minutes …

Spreading the word about Jay’s awesome findings on the libdrizzle benchmark against the original library inherited from MySQL. For those that aren’t familiar with libdrizzle, it is a fresh new (modern implementation) MySQL compatible client library for Drizzle that leverages asynchronous I/O and smarter memory usage founded by Eric Day.

You can read how this library came to life in this thread:

• https://lists.launchpad.net/drizzle-discuss/msg00472.html

As you can see in Jay’s findings with sysbench, libdrizzle outperforms the original library in all concurrency …

I have been benchmarking Waffle Grid using the new Innodb Plugin 1.03 the past couple of days. Let me say the plugin is fast. Which got me thinking, generally when you fix a bottleneck another area becomes a bottleneck… its a vicious cycle really. I figured why not benchmarks several different settings just to see what sort of improvement or detriment we get in Inno. This hopefully will lead to the next place to look for potential performance improvements. For the test I chose a somewhat IO bound setup and a CPU bound setup.

The IO bound setup was a 20W test, 768M buffer pool.
The CPU boud setup was a 20W test, 5GB buffer pool.

I decided to start with the Double Write Buffer. For those who are not familiar with the double write buffer check out the docs or …

Some months ago, Google released a patch for InnoDB that boosts performance on multi-core servers. We decided to incorporate the change into the InnoDB Plugin to make everybody happy: users of InnoDB don’t have to apply the patch, and Google no longer has to maintain the patch for new versions of InnoDB. And it makes us at Innobase happy because it improves our product (as you can in this post about InnoDB Plugin release 1.0.3).

However, there are always technical and business issues to address. Given the low-level changes in the patch, was it technically sound? Was the patch stable and as rock solid as is the rest of InnoDB? Although it was written for the built-in InnoDB in MySQL 5.0.37, we needed to adapt it to the InnoDB Plugin. Could we …

I don’t know if it is because of my science background, I am a physicist, I do like graphs, especially when I do performance tuning. With UNIX like operating systems, the vmstat command give you an easy way to grab many essential performance counters but, generating graphs from vmstat output with tools like OpenOffice Calc is time consuming and not very efficient. In order to solve this, I wrote a few scripts using gnuplot but they are not very easy to work with. Then, doing some benchmarks with DBT2, I found the vmplot.sh script and… I like that one. I just hacked it little bit to make it keeps the graph on screen, adding the “-persist” parameters to the gnuplot invocations. The script will produce 7 graphs that will be displayed on screen and save in png format in /tmp. The graphs it produces are the following:

• CPU: graphs idle, user, sys and wait time
• …

So we have already looked at sysbench & dbt2 tests… now we have to look at the new Juice DB benchmark. Juice runs a series of queries generate its load, these queries are combined into a workload. I tested the v1010 with a mixed workload ( mix of short & long updates and selects ), a mixed simple workload ( mix of short running updates and selects ) , and a read only ( selects which are designed to hit the disk ) . Because this is still an evolving benchmark I am including results from an Intel MLC drive (note these boxes are vastly different).  Keep in mind this is not a completely fair comparison. The Intel drive is not the enterprise class drive, but even with the SLC drive I don’t think its a fair comparison. The price difference between these two solutions is ~$50/GB -vs- ~$12.5GB.

The setup for this test created about a 20GB database, with each of the 3 large tables coming in around 6 GB each. I tested primarily with a 768M …