Quantcast
Viewing all articles
Browse latest Browse all 18769

Performance schema or COM_ status counters ?


In MySQL 5.6.3, that is, a while ago already, the performance schema added instrumentation for statements.

This major enhancement seem to have gone unnoticed, so a quick review of how it works, especially compared to the existing COM_ status counters that everyone is used to, can perhaps put some light here.

The MySQL server maintains 'COM_%' counters for statements executed.

These counters are available in both the session and global status.

Let's look at a few:

mysql> select variable_name from information_schema.global_status
where variable_name like "com\_%" order by variable_name limit 20;
+------------------------+
| variable_name          |
+------------------------+
| COM_ADMIN_COMMANDS     |
| COM_ALTER_DB           |
| COM_ALTER_DB_UPGRADE   |
| COM_ALTER_EVENT        |
| COM_ALTER_FUNCTION     |
| COM_ALTER_PROCEDURE    |
| COM_ALTER_SERVER       |
| COM_ALTER_TABLE        |
| COM_ALTER_TABLESPACE   |
| COM_ANALYZE            |
| COM_ASSIGN_TO_KEYCACHE |
| COM_BEGIN              |
| COM_BINLOG             |
| COM_CALL_PROCEDURE     |
| COM_CHANGE_DB          |
| COM_CHANGE_MASTER      |
| COM_CHECK              |
| COM_CHECKSUM           |
| COM_COMMIT             |
| COM_CREATE_DB          |
+------------------------+
20 rows in set (0.00 sec)

Now, let's take a look at what is instrumented in the performance schema, for statements:

mysql> select name from setup_instruments
where name like "statement/sql/%" order by name limit 20;
+----------------------------------+
| name                             |
+----------------------------------+
| statement/sql/                   |
| statement/sql/alter_db           |
| statement/sql/alter_db_upgrade   |
| statement/sql/alter_event        |
| statement/sql/alter_function     |
| statement/sql/alter_procedure    |
| statement/sql/alter_server       |
| statement/sql/alter_table        |
| statement/sql/alter_tablespace   |
| statement/sql/analyze            |
| statement/sql/assign_to_keycache |
| statement/sql/begin              |
| statement/sql/binlog             |
| statement/sql/call_procedure     |
| statement/sql/change_db          |
| statement/sql/change_master      |
| statement/sql/check              |
| statement/sql/checksum           |
| statement/sql/commit             |
| statement/sql/create_db          |
+----------------------------------+
20 rows in set (0.00 sec)

The resemblance is striking. In fact, the names present in performance_schema.setup_instruments are derived from the COM_ names, with a few tweaks.

For real SQL statements, such as ALTER TABLE, 'COM_ALTER_TABLE' corresponds to 'statement/sql/alter_table'.

For what show status advertizes as 'admin commands', which is just a common bucket for different things, the performance schema instrumentation actually is more detailed, and gives each command a real name, so that commands from the client/server protocol are visible too:

mysql> select name from setup_instruments
where name like "statement/com/%" order by name;
+------------------------------+
| name                         |
+------------------------------+
| statement/com/Binlog Dump    |
| statement/com/Change user    |
| statement/com/Close stmt     |
| statement/com/Connect        |
| statement/com/Connect Out    |
| statement/com/Create DB      |
| statement/com/Daemon         |
| statement/com/Debug          |
| statement/com/Delayed insert |
| statement/com/Drop DB        |
| statement/com/Error          |
| statement/com/Execute        |
| statement/com/Fetch          |
| statement/com/Field List     |
| statement/com/Init DB        |
| statement/com/Kill           |
| statement/com/Long Data      |
| statement/com/Ping           |
| statement/com/Prepare        |
| statement/com/Processlist    |
| statement/com/Query          |
| statement/com/Quit           |
| statement/com/Refresh        |
| statement/com/Register Slave |
| statement/com/Reset stmt     |
| statement/com/Set option     |
| statement/com/Shutdown       |
| statement/com/Sleep          |
| statement/com/Statistics     |
| statement/com/Table Dump     |
| statement/com/Time           |
+------------------------------+
31 rows in set (0.00 sec)

Overall, there are 140 'COM_%' entries in show status, for 165 'statement/%' entries in the performance schema. The performance schema also count errors with special entries, which is not available in show status. All the details are explained in the documentation.

Now, what about the statistics collected by the statement instrumentation then ?

In SHOW STATUS, each 'COM_%' entry is only a counter. There are counters for the current session (aka your own connection), and global counters.

In the performance schema, there are more detailed statistics and not just a counter. These statistics are for every session (table statements_summary_by_thread_by_event_name) or global (table statements_summary_global_by_event_name).

In fact, there are even more levels of aggregation as intermediate steps between SESSION and GLOBAL, with statistics by account, user or host, which the SHOW STATUS command do not provide.

The difference between 'current session' and 'every session' is fundamental ... a monitoring tool needs to see what a monitored application is doing, not itself.

As for details about the data provided, let's take a quick look:

For SHOW STATUS:

mysql> select * from information_schema.global_status
where variable_name like "com_select" \G
*************************** 1. row ***************************
 VARIABLE_NAME: COM_SELECT
VARIABLE_VALUE: 34
1 row in set (0.00 sec)

For the performance_schema:

mysql> select * from performance_schema.events_statements_summary_global_by_event_name
where event_name like "statement/sql/select" \G
*************************** 1. row ***************************
                 EVENT_NAME: statement/sql/select
                 COUNT_STAR: 34
             SUM_TIMER_WAIT: 103780188000
             MIN_TIMER_WAIT: 76388000
             AVG_TIMER_WAIT: 3052358000
             MAX_TIMER_WAIT: 39010345000
              SUM_LOCK_TIME: 3818000000
                 SUM_ERRORS: 1
               SUM_WARNINGS: 0
          SUM_ROWS_AFFECTED: 0
              SUM_ROWS_SENT: 1441
          SUM_ROWS_EXAMINED: 10574
SUM_CREATED_TMP_DISK_TABLES: 2
     SUM_CREATED_TMP_TABLES: 14
       SUM_SELECT_FULL_JOIN: 0
 SUM_SELECT_FULL_RANGE_JOIN: 0
           SUM_SELECT_RANGE: 0
     SUM_SELECT_RANGE_CHECK: 0
            SUM_SELECT_SCAN: 31
      SUM_SORT_MERGE_PASSES: 0
             SUM_SORT_RANGE: 0
              SUM_SORT_ROWS: 1071
              SUM_SORT_SCAN: 24
          SUM_NO_INDEX_USED: 31
     SUM_NO_GOOD_INDEX_USED: 0
1 row in set (0.00 sec)

There are even more differences.

Having statistics is great, but people need to reset them once in a while, still when doing monitoring.

For SHOW STATUS, the command FLUSH STATUS has shortcomings. See feature requests like bug#22875 about it.

The performance schema actually provides the functionality to reset statistics.

The syntax is a bit different: the missing 'FLUSH SESSION STATUS' corresponds to 'TRUNCATE TABLE performance_schema.events_statements_summary_by_thread_by_event_name'.

It is all there in 5.6.3

-- Marc Alff, Oracle.

Image may be NSFW.
Clik here to view.

PlanetMySQL Voting: Vote UP / Vote DOWN

Viewing all articles
Browse latest Browse all 18769

Trending Articles