MySQL Performance Blog

Following on from our earlier announcement, Paul McCullagh has responded with the answers to your questions – as well as a few I gathered from other Percona folks, and attendees of OpenSQL Camp. Thank you Paul!

What’s the “ideal” use case for the PBXT engine, and how does it compare in performance?  When would I use PBXT instead of a storage engine like MyISAM, InnoDB or XtraDB?

[read more...]

There is the rare bug which I ran into every so often. Last time I’ve seen it about 3 years ago on MySQL 4.1 and I hoped it is long fixed since… but it looks like it is not. I now get to see MySQL 5.4.2 in the funny state.

When you see bug happening you would see MySQL log flooded with error messages like this:

091119 23:03:34 [ERROR] Error in accept: Resource temporarily unavailable
091119 23:03:34 [ERROR] Error in accept: Resource temporarily unavailable
091119 23:03:34 [ERROR] Error in accept: Resource temporarily unavailable
091119 23:03:34 [ERROR] Error in accept: Resource temporarily unavailable

filling out disk space
[read more...]

Recently I looked at table_cache sizing which showed larger table cache does not always provides the best performance. So I decided to look at yet another similar variable – innodb_open_files which defines how many files Innodb will keep open while working in innodb_file_per_table mode.

Unlike MyISAM Innodb does not have to keep open file descriptor when table is open – open table is purely logical state and appropriate .ibd file may be open or closed. Furthermore besides MySQL table_cache Innodb maintains its own (called data dictionary) which keeps all tables ever accessed since table start – there is no variable to control its size and it can take significant amount of memory in some edge cases. Percona patches though provide innodb_dict_size_limit to restrict growth of data dictionary.
[read more...]

Dear Community,

We are pleased to present the 20th build of MySQL server with Percona patches.

Comparing to the previous release it has following new features:

• The build is based on MySQL-5.0.87
• innodb_rw_lock.patch is ported from InnoDB Plugin 1.0.3
• To be compatible with RedHat RPM repository, the naming scheme has changed to

  <rpm name>-<mysql version>-<percona build version>.<buildnumber>.<redhat version>.<architecture>.rpm

  Example:

  MySQL-server-percona-5.0.87-b20.29.rhel5.x86_64.rpm

See release notes for earlier changes.

Since the build 20 MySQL server with Percona patches is available in Percona RPM repository via YUM. To make it working add a file Percona.repo in /etc/yum.repos.d with following content

As usual you can download binaries and sources with the patches here
http://www.percona.com/mysql/5.0.87-b20/

There is Debian packages repository is also available. See release page for configuration and usage guideance.

The Percona patches live on Launchpad : https://launchpad.net/percona-patches and you can report bug to Launchpad bug system:

https://launchpad.net/percona-patches/+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.

innodb_rw_lock.patch

Couple of months ago there was a post by FreshBooks on getting great performance improvements by lowering table_cache variable. So I decided to investigate what is really happening here.

The "common sense" approach to tuning caches is to get them as large as you can if you have enough resources (such as memory). With MySQL common sense however does not always works - we've seen performance issues with large query_cache_size also sort_buffer_size and read_buffer_size may not give you better performance if you increase them. I found this also applies to some other buffers.
[read more...]

A final update on training for this year - registration for InnoDB/XtraDB training in Chicago (8th December) and Atlanta (10th December) are now open.

While in Atlanta I'll be giving a talk at the Atlanta PHP User Group on Optimizing MySQL Performance (details to be posted to their website shortly).  If you're in Chicago and would like me to speak at your group on 7th-8th December, let me know!

I forwarded on a list of questions about PBXT to Paul McCullagh today.  While Paul's busy answering them, I'd like to announce that Robert Dempsey (InfiniDB storage engine) and Bradley C. Kuszmaul (TokuDB storage engine) have also accepted an interview. If you have any questions about either storage engine, please post them here by Friday 20th November.

I wrote a post a while back that said why you don't want to shard.  In that post that I tried to explain that hardware advances such as 128G of RAM being so cheap is changing the point at which you need to shard, and that the (often omitted) operational issues created by sharding can be painful.

What I didn't mention was that if you've established that you will need to eventually shard, is it better to just get it out of the way early?  My answer is almost always no. That is to say I disagree with a statement I've been hearing recently; "shard early, shard often".  Here's why:

• There's an order of magnitude better performance that can be gained by focusing on query/index/schema optimization.  The gains from sharding are usually much lower.
• If you shard first, and then decide you want to tune query/index/schema to reduce server count, you find yourself in a more difficult position - since you have to apply your changes across all servers.

Or to phrase that another way:
I would never recommend sharding to a customer until I had at least reviewed their slow query log with mk-query-digest and understood exactly why each of the queries in that report were slow.  While we have some customers who have managed to create their own tools for shard automation, it's always easier to propose major changes to how data is stored before you have a cluster of 50+ servers.

When I did NDB Cluster engagements, it happened a few time that I had to cover the NDB API. Once, a customer asked an example on how to perform a simple scan. Remembering that some examples are within the NDB source tree, under ./storage/ndb/ndbapi-examples/ and I decided to take a look, why writing something when a good example already exists... I was not expecting what I found!
[read more...]

In the last 2 blog posts about High Availability for MySQL we have introduced definitions and provided a list of ( questions that you need to ask yourself before choosing a HA solution. In this new post, we will cover what is the most popular HA solution for MySQL, replication.
[read more...]