If you haven’t explored the MySQL Performance Schema yet, this is a good place to start. This is Performance Schema 101, a basic introduction to the MySQL 5.6 performance_schema, which records runtime statistics from the MySQL database. The performance_schema is intended to provide access to useful information about server execution while having minimal impact on server performance. Performance_schema is the name of both the storage engine and the database itself, and it was initially implemented in MySQL 5.5. In MySQL 5.6 the engineers added quite a bit of new instrumentation.
The performance_schema database uses views or temporary tables that actually use little to no persistent disk storage .Memory allocation is all done at server startup, so there is no ongoing memory reallocation or sizing, which is great for performance.
I categorize the performance_schema tables into four areas:
Image may be NSFW.
Clik here to view.
Types of Tables in the Performance Schema
The Setup tables keep track of the logistics – who, what, and how to monitor, and where to save this data. Its important to understand what is in these tables so you know who and what is being reported on and what can be changed.
Current Events tables contain the most recently collected monitored event.
History tables are similar to Current Events tables, but contain a history of what has occurred over time.
Object Instances tables record what instances of objects (files, locks, mutexes, etc) are instrumented.
In this post we will take a closer look at the setup tables. Most tables in the performance_schema are read only, but some of the setup tables allow data manipulation language (DML) so that configuration can be changed. Remember, however, that all tables are cleared when the server is shut down. There are also options you can set in the .cnf file for some setup values, discussed below. There are five setup tables:
Image may be NSFW.
Clik here to view.
Setup tables (Note all tables are prefixed with setup_ )
Who to Monitor Image may be NSFW.
Clik here to view.
The setup_actors table tells MySQL who to monitor. It contains only three columns, HOST, USER, and ROLE (the latter is not currently used). The performance schema looks in the setup_actors table to see if a connecting thread should be monitored. Initially this table is set for monitoring of all foreground threads (all fields are set to %).
Image may be NSFW.
Clik here to view.
You can insert, update and delete rows, for example if you want to monitor only a specific user, or if you want to exclude a set of users like batch loading jobs. Change the HOST and USER fields to indicate this. Any changes to this table apply only to new connections.
Image may be NSFW.
Clik here to view.
What tables to monitor
The setup_objects table contains the tables you are Image may be NSFW.
Clik here to view.
monitoring. By default, all tables are monitored except those in the mysql, performance_schema, and information _schema databases.
Image may be NSFW.
Clik here to view.
If you have a table that you don’t want to monitor, for example a logging table, you can exclude it through use of this table. The default size for this table is 100 rows, but the size can be increased through the performance_schema_setup_objects_size variable.
How to modify: Insert or update this table.
What instrumentation to collect
The setup_instruments table indicates what can be monitored by listing the Image may be NSFW.
Clik here to view.
“instruments” currently available in the MySQL Server. Think of the MySQL Server as being or equipped with pieces of code that perform specified functions or measurement, called “instruments”. Each of these coded instruments can collect certain specific information. Each instrument has a NAME that begins with one of four categories: statement, stage, idle, or wait. Instruments use a naming convention (linear taxonomy) that goes from general on the left to specific on the right, for example:
statement/sql/create_table wait/io/file/myisam/log
- Statement indicates a sql statement (like SELECT) or command (like CONNECT)
- Stages is the stage of statement processing, the , like SORTING RESULT
- Wait is an instrumented wait event, like WAIT I/O/FILE or WAIT/LOCK
- Idle is when a connection is idle, that is, a socket is idle if it is waiting for a request from the client
There are over 500 instruments listed in this table in 5.6. You will not normally need to collect on all the instrumentation, so each instrument can be enabled or disabled. Out of the box, less than half of these instruments are enabled (ENABLED = ‘YES’) . If an instrument is not enabled, no information is collected. When and if you need to investigate in more detail, the other instruments can be set as needed by updating the ENABLED column. The TIMED column indicates whether that instrument is timed or not. If it is, the unit of measurement is stored in the setup_timers table
Image may be NSFW.
Clik here to view.
You can also control instruments at server startup with the option –performance_schema_instrument = ‘instrument_name=value’
To control an instrument at server startup, use an option of this form: --performance_schema_instrument='instrument_name=value'
Where To Store It
The setup_consumers table indicates where the monitored data will go. The Image may be NSFW.
Clik here to view.
setup_consumers table has only two columns – NAME and ENABLED.
Image may be NSFW.
Clik here to view.
The global_instrumentation consumer is the highest level and must be enabled for any monitoring to be collected in tables. If the global_instrumentation column is enabled, then instrumentation for global states is kept, and the next level, thread_instrumentation is checked. If thread_instrumentation is enabled, the Performance Schema maintains thread-specific information. Most consumers NAMES are tables (the events% listed above) where data will be written. Note that several of the tables are history tables, which could be disabled if you are not interested in keeping history.
We also have digest tables. The statements_digest contains a normalized view of SQL statements, taking out specific values, white space, and comments from similar SQL statements and grouping them together. You can then see what groups of statements are executing and how frequently they run. If the statements_digest is enabled, this information gets written to the events_statements_summary_by_digest table.
How to modify: Update or use performance_schema_consumer_name=value
At the MySQL Virtual Developers Day , Mark Leith gave a great talk explaining the MySQL performance schema. This talk is now available online:
https://oracle.6connex.com/portal/mysql/login/
Mark also has an excellent blog:
http://www.markleith.co.uk/2012/07/13/monitoring-processes-with-performance-schema-in-mysql-5-6/
Marc Alff’s blog post : On configuring the Performance Schema http://marcalff.blogspot.com/2013/04/on-configuring-performance-schema.html?m=1
We have excellent documentation available on the performance schema:
http://dev.mysql.com/doc/refman/5.5/en/performance-schema.html
I hope you enjoy exploring the performance_schema.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
