Monthly Archives: October 2010

Post navigation

Another piece of good news for MySQL 5.5 – the output of SHOW ENGINE INNODB STATUS has now been increased from 64kB, to 1MB. For those running with systems that have thousands of running transactions, or large lock outputs, it should take quite a bit more to force truncation now.

We also added a new status variable to track when truncation happens as well – innodb_truncated_status_writes, so you can detect this should you have automated monitoring depending on this output.

Share this:

Like this:

Leading up to my previous post, I had been doing some work to start the integration of PERFORMANCE_SCHEMA data with MySQL Enterprise Monitor, including some new graphs based on some of the data that I talked about in the above post..

A picture tells a thousand words:

This is only scratching the surface – more to come, watch this space!

Share this:

Like this:

Mark Callaghan over at Facebook wrote a note recently about InnoDB disk IO counters in SHOW STATUS, with some extra things that he wanted to track. I posted a quick comment over there, but I thought this deserved it’s own write up.

MySQL 5.5’s PERFORMANCE_SCHEMA has had a fair bit written about it in terms of tracking synchronization point contention (mutexes etc.), but it currently tracks two orders within the wait class – these are /wait/synch and /wait/io.

Actually, allow me to detour first, it’s not clear from the documentation, though it is clear in the worklog. Each event within PERFORMANCE_SCHEMA is a specific instrumentation point, tracked in some way, such as recording the time taken to complete the event (a specific code section). The naming convention for each event follows Linnaean taxonomy – /Class/Order/Family/Genus/Species. We currently have one major class – /wait.

The /wait/io order has one family within it currently – /wait/io/file, which instruments all file IO for the SQL layer (the /wait/io/file/sql genus), tracking binary logs, frm file access, info files, etc., as well as for all table/index file IO done by instrumented storage engines (such as the /wait/io/file/innodb / /wait/io/file/myisam genera).

Mark shows in his blog how you can already get some pretty good statistics on what is taking up IO on the server, so let’s look at how we can fix some of the deficiencies mentioned, such as:

“Innodb_data_writes describes the number of writes done but all writes are not created equal. Writes to the log file are small and use buffered IO. These are much less expensive that writes done to update InnoDB pages in place. But Innodb_data_writes does not distinguish between them.”

“Innodb_pages_written describes the number of pages written but not the number of IO requests used to write them as write requests for adjacent pages can be merged and some of the code that schedules pages to be written attempts to find adjacent dirty pages to be written at the same time.”

This is actually really easy to track with PERFORMANCE_SCHEMA now that InnoDB has been fully instrumented. InnoDB has created 3 individual species within it’s own genus:

/wait/io/file/innodb/innodb_data_file – file IO for central or single tablespace data files/wait/io/file/innodb/innodb_log_file – redo log file IO/wait/io/file/innodb/innodb_temp_file – IO against a sort merge file that is used when adding indexes

Mark’s problem focuses on the high level, looking at IO as single counters for what is almost specific species of IO, which relates to FILE_SUMMARY_BY_EVENT_NAME. An example of the data that you can get (scroll to the right):

But wait, it doesn’t end there. Mark also wants to be able to break out writes to things like the doublewrite buffer. This is hard to do when tracking data file IO alone as single counters as above, because all writes to the doublewrite buffer also go to the central tablespace’s data file.

Of course, you can SELECT the value for Innodb_dblwr_writes as Mark does and subtract that from the above counters if you want to, but I have a slightly different example using the FILE_SUMMARY_BY_INSTANCE table.

When using innodb_file_per_table (and if you are not, why not? ;)), you also get the added benefit that any data file IO for tables is tracked individually, here’s an example of finding the top 10 consumers:

The database instance the above comes from is only using innodb_file_per_table tables, so why all the writes to the central tablespace? Two major reasons.. The doublewrite buffer, and the undo log..

Also note that we can get down to the partition level here as well, so we can find hot partitions too.

Subtracting the doublewrite overhead from the central tablespace datafile IO should give you the added benefit of also drilling in to undo log IO writes as well (perhaps with some extra fuzz factor for other writes to the central tablespace that happen).