New performance schema features in 5.6.4

As development of the 5.6 serie continues, a new milestone (5.6.4) is now available.

The source code for mysql-trunk is on launchpad, and the MySQL 5.6 documentation is also public.

In this milestone, a few new performance schema features have been implemented, as can be seen in the changelog.

MY.CNF, or easier configuration

Until now, the performance schema used a very simple, or shall I say, crude, way to decide what needs to be instrumented or not: flip the master switch on (performance_schema), and you get absolutely everything available, with as much details as possible, by default. And then, to change the defaults, the only way was to use DML statements to tell the performance schema to do less.

With the number of instrumented artifacts growing (table setup_instruments went from 212 entries in 5.5 to 503 entries in 5.6.4), and with the number of tables also growing (the performance_schema database went from 17 tables in 5.5 to 48 tables in 5.6.4), there is now the need for a better, easier way to control the instrumented content.

The first major change implemented is that instead of getting all the available instrumentation enabled by default, only a selected few instruments are enabled. For example, not every DBA is interested in knowing the low level implementation details of the server code itself, so things that are only fascinating to server developers like mutexes are disabled. Conversely, DBA are likely to be looking often at statements that applications are executing against the server, so all the statement instrumentation is enabled by default. Nothing is hard coded and everything can be changed. By providing a configuration "out of the box" that is much closer to real production scenarios, the extra work to configure the performance schema exactly how you want it is reduced, a lot.

Similar to limiting which instrument is enabled in the table setup_instruments, the list of consumers enabled by default, which basically controls how much details the instrumentation provides, has been revised. Consumers such as event histories, which contributed a lot to the performance schema overhead only to maintain tables that are after all rarely used, have been turned off by default.

The second major change is that the performance schema does not need to be told again, with DML, what to do after each server startup. The specification about settings in tables setup_instruments and setup_consumers, which again define how many different events are collected and with which level of details, can be written in the server my.cnf file. The syntax in the my.cnf file is simple and powerful enough so that one can tell in one line "disable all the mutexes" or "enable all the file io in this storage engine", without having to even spell out each and every instruments (remember that there are 500+ by now) known to the performance schema.

In short, this new feature should be good news to many people, especially early adopters.

END_EVENT_ID, or easier ways to access hierarchical data

The performance schema provides data. A lot. With many details.

When looking in particular at individual events, instead of just statistics with aggregations, these events (statements, stages, waits of many different type) all relate to each others and form collectively a big hierarchical data tree.

For a good description of hierarchical data and methods to manipulate it, see this excellent article.

The performance schema tables were already supporting the 'Adjacency List Model', with columns such as NESTING_EVENT_ID in an event pointing to EVENT_ID in a parent event.

With 5.6.4 and the introduction of columns like END_EVENT_ID, the performance schema tables are now also supporting the 'Nested Set Model'.

That's right, we now support both models, so an application can use what makes the most sense given the use case.

Why is that important ? Well, people like Mark Leith convinced me that it is, in particular because it helps a lot to navigate the data efficiently, for example to produce big fancy graphs.

Extended file io statistics

The file io instrumentation was added in the performance schema in 5.5 already. Unfortunately, the statistics collected by file in 5.5 are not very informative, as only a few columns are provided.

With 5.6.4, the summaries for file io have been revised and improved, to provide more content.

To see the difference, compare side by side the 5.5 documentation and the 5.6 documentation, and see the new columns.

Reminder

MySQL 5.6.4 is not a GA release, and should not be used in production.


-- Marc Alff, Oracle.



PlanetMySQL Voting: Vote UP / Vote DOWN