MySQL Performance Blog

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.

From our side we will look on recent improvements and also on Google V3 patches and will integrate them into next release of XtraDB, so stay tuned

MySQL 5.4 comes with Innodb engine which seems to have much better performance than MySQL 5.0 – this is due to locking and IO patches from Google integrated in this release (which are similar to appropriate Percona patches) as well as some unique fixes such as different innodb_thread_concurrency handling and other optimization.

Should we take Innodb from MySQL 5.4 and merry it with unique Percona patches (adaptive checkpoints, additional undo slots, profiling, etc) and integrate it with MySQL 5.0 ? How useful would you find it ?
[read more...]

We announce next beta version of our xtrabackup tool.

Changelist includes:

- set innodb_fast_shutdown=1 on xtrabackup shutdown
- set innodb_write_io_threads=10 by default for fast buffer_pool flushing during recovery
- build xtrabackup with –with-extra-charsets=complex
Bug #357653: innobackupex-1.5.1 –copy-back fails
Bug #358194: 2nd-phase is very slow
Bug #358266: xtrabackup-0.5 dies with SEGV on bad command line arguments
Bug #359341: innobackupex still does not read defaults-file

You can download current binaries RPM for RHEL4 and RHEL5 (compatible with CentOS also), DEB for Debian/Ubuntu and tar.gz for Mac OS / Intel 64bit there:
http://www.percona.com/mysql/xtrabackup/0.6/.
By the same link you can find general .tar.gz with binaries which can be run on any modern Linux distribution.
By the same link you can download source code if you do not want to deal with bazaar and Launchpad.

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona

(Note: Review was done as part of our consulting practice, but is totally independent and fully reflects our opinion)

I had a chance to take look TokuDB (the name of the Tokutek storage engine), and run some benchmarks. Tuning of TokuDB is much easier than InnoDB, there only few parameters to change, and actually out-of-box things running pretty well.

There are some rumors circulating that TokuDB is ”.. only an in memory or read-only engine, and that’s why inserts are so fast”. This is not actually the case, as TokuDB is a disk-based, read-write transactional storage engine that is based on special “fractal tree indexes”. Fractal Trees are a drop-in-replacement for a B-tree (based on current research in data structures by professors at Stony Brook, Rutgers, and MIT). I can’t say exactly how it is improved, because the engine itself is closed source.
[read more...]

Today we glad to announce release 1.0.3-5 of our XtraDB storage engine.

Here is a list of enhancements in this release:

• move to MySQL 5.1.34
• removed rw_lock patch, so we now use Google’s rw_locks
• fix crash after upgrade 5.1.31 -> 5.1.33
• fix mysql-test

Percona XtraDB 1.0.3-5 available in source and several binary packages.

XtraDB is compatible with existing InnoDB tables (unless you used innodb_extra_undoslots) and we are going to keep compatibility in further releases. We are open for features requests for new engine and ready to accept community patches. You can monitor Percona’s current tasks and further plans on the Percona XtraDB Launchpad project. You can also request features and report bugs there. Also we have setup two maillists for General discussions and for Development related questions.

The 2009 Percona Performance Conference finished up last week, and was overall a resounding success. Thanks to all of the speakers, O’Reilly, and Sun/MySQL for help making it happen! Most slides have been uploaded; look for the stragglers over the next couple of days.

Having trouble finding the Percona Performance Conference? It’s upstairs near where the registration desk was (aka above the exhibition hall). Hope to see you there today & tomorrow!

This year we’ve assembled a team of seven Perconian representatives for the MySQL Conference & Expo/Percona Performance Conference. If you like a particular blog post we’ve written over the last year, have any other feedback, or just want to say hello – we’d like to meet you!

From left to right; Morgan, Ewen, Baron, Vadim, Peter, Tom, Ryan.

We’ll be at the Percona Performance Conference (Wed & Thur), at the Percona booth inside the exhibition hall (Tue & Wed), and at the Maatkit booth in the dot-org pavilion.   Feel free to bring your technical questions to booth #528, where a consultant will be available.   We’ll try our best to help you for the price of a free beer! 

In the recently released Sphinx version 0.9.9-rc2 there is a support for MySQL wire protocol and SphinxQL – SQL-like language to query Sphinx indexes. This support is currently in its early preview stage but it is still fun to play with.

A thing to mention – unlike MySQL Storage Engines, some of which as InfoBright or KickFire take over execution after parsing, Sphinx MySQL support has nothing to do with MySQL – it is implementation of the wire protocol from scratch.

For this test I was not interesting in the full text search performance, we already know Sphinx is much faster than MySQL build in full text search. I was rather interested to look performance of other queries, not using Full Text Search.
[read more...]

Sometimes a MySQL server running InnoDB takes a long time to shut down. The usual culprit is flushing dirty pages from the buffer pool. These are pages that have been modified in memory, but not on disk.

If you kill the server before it finishes this process, it will just go through the recovery phase on startup, which can be even slower in stock InnoDB than the shutdown process, for a variety of reasons.

[read more...]