Recent scalability fixes in InnoDB and also Google's and your SMP fixes almost made InnoDB results acceptable in primary key lookups queries, but secondary indexes were forgotten for some time. Now having Dell PowerEdge R900 on board (16CPU cores, 16GB RAM) I have some time for experiments, and I played with queries

PLAIN TEXT CODE:

1. SELECT name  FROM sbtest WHERE country_id = ? LIMIT 5

against table

PLAIN TEXT CODE:

1. CREATE TABLE IF NOT EXISTS sbtest (
2.                   id int(10) unsigned NOT NULL auto_increment,
3.                   name varchar(64) …

After several important fixes to our patches we made binaries for build12.

Fixes include:

Control of InnoDB insert buffer to address problems Peter mentioned http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/, also check Bug 41811 to see symptoms of problem with Insert buffer.

http://www.percona.com/docs/wiki/patches:innodb_io_patches

* innodb_flush_neighbor_pages (default 1) - When the dirty page are flushed (written to datafile), this parameter determines whether the neighbor pages in the datafile are also flushed at the same time or not. If you use the storage …

Percona has been building and contributing to open-source software since the company was founded, and individually we've been doing the same thing for many years.  We think it's a huge value for our customers and the community.

We're involved in a dozen or so open-source projects, but our three core efforts at the moment are the following:

• Percona patches, which are included in our own MySQL builds and then in OurDelta builds and perhaps others as well
• XtraDB, which is our new high-performance transactional storage engine
• Maatkit, which is a toolkit that provides advanced functionality for MySQL.

We have a team of dedicated MySQL developers working on the server …

As you may know Sun / MySQL made release of community 5.0.75 only as source code release. We made binaries with our patchset.
Patches are mostly equal to build 10
http://www.mysqlperformanceblog.com/2008/12/11/mysql-binaries-percona-build10/, only change:
it includes bugfix for https://bugs.launchpad.net/percona-patches/+bug/308849

You can download binaries (RPMS x86_64) and sources with patches here
http://www.percona.com/mysql/5.0.75-b11/

Entry posted by Vadim | 7 comments

Add to: …

Peter said me that previous results http://www.mysqlperformanceblog.com/2008/12/18/xtradb-benchmarks-15x-gain/ are too marketing, and we should show other results also.

Here is the run for CPU Bound,or it would be more correctly to say in-cache benchmark, because there is a lot of CPU remains idle. This run is exactly the same as Disk Bound but with innodb_buffer_pool_size=8G which is more than enough to fit all data in memory.

The XtraDB is showing very modest gain of about 2.5% in this case which can be attributed to measurement error too.

The story becomes more …

We made new binaries for MySQL 5.0.67 build 10 which include next fixes:

• We addressed concerns about potential logging and statistics overhead, so now you can fully turn on / off query statistics for microslow patch and user statistics in runtime.

Next variables were added:

PLAIN TEXT CODE:

1. | slow_query_log                  | ON                                           |
2. | slow_query_log_file             | /var/lib/mysql/slow_query.log                |
3. for …

After some discussions on the OpenSQLCamp 2008 conference we decided to move our development to Launchpad, to be in stream with other MySQL related projects.

We published our patches there https://code.launchpad.net/percona-patches, it is supposed to be main repository for the patches.

We advise to use Launchpad bug system to report bugs and also for feature requests.

Entry posted by Vadim | No comment

Add to: | …

We made new binaries for MySQL 5.0.67 build 7 which include patches we recently announced.

The -percona release includes:

PLAIN TEXT CODE:

1. | innodb_check_defrag.patch                        | Session status to check fragmentation of the last InnoDB scan                            | 1.0     | Percona <info@percona.com>       | GPL     | The names are Innodb_scan_*                      …

Do you know that there are two limits about dirty (modified but not flushed to disk) blocks of InnoDB buffer pool? One is the limit of "amount". The other is the limit of "age".

-- limit of "amount" --

As you know, buffer pool of InnoDB works as write-back cache of its datafiles. If the buffer pool is filled by dirty blocks, InnoDB cannot allocate new blocks without flushing the dirty blocks and the performance would get worse. This is the limit of dirty block "amount". We can avoid this limit by setting 'innodb_max_dirty_pages_pct' smaller or setting the larger buffer pool size. We might be never at a loss about the limit.

The another limit we should understand is limit of dirty block "age".

-- limit of "age" --

As you know again, because InnoDB write the modifies of datafile to transaction log file synchronously, InnoDB is allowed to treat its buffer pool as write-back …

After some pause we are going to announce bunch of patches we made and ported for last period.

Ported patches (ported from Google V2 patch):

1. -

innodb_fsync_source.patch - Show information about callers of fsync, more info

1. -

innodb_io_tune.patch - Port of two patches InnodbIOTune and InnodbAsync, more info

1. -

…