25.1 Начало работы со схемой производительности
В этом разделе кратко представлена схема производительности с примерами ее использования. Для получения дополнительных примеров см. Раздел 25.19, «Использование схемы производительности для диагностики проблем».
Схема производительности включена по умолчанию. Чтобы явно включить или отключить ее, запустите сервер с переменной performance_schema установленной на соответствующее значение. Например, используйте эти строки в файле конфигурации сервера my.cnf:
[mysqld]
performance_schema=ON
При запуске сервер видит performance_schema и пытается инициализировать схему производительности. Для проверки успешной инициализации используйте это утверждение:
mysql> SHOW VARIABLES LIKE 'performance_schema';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| performance_schema | ON |
+--------------------+-------+
Значение ON означает, что схема производительности инициализирована успешно и готова к использованию. Значение OFF означает, что произошла ошибка. Проверьте журнал ошибок сервера для получения информации о возникшей проблеме.
Схема производительности реализована как движок хранения. Если этот движок доступен (что вы уже должны были проверить ранее), вы должны увидеть его в списке со значением SUPPORT равным YES в выводе из таблицы Информационной схемы ENGINES или оператора SHOW ENGINES:
mysql> SELECT * FROM INFORMATION_SCHEMA.ENGINES
WHERE ENGINE='PERFORMANCE_SCHEMA'\G
*************************** 1. row ***************************
ENGINE: PERFORMANCE_SCHEMA
SUPPORT: YES
COMMENT: Performance Schema
TRANSACTIONS: NO
XA: NO
SAVEPOINTS: NO
mysql> SHOW ENGINES\G
...
Engine: PERFORMANCE_SCHEMA
Support: YES
Comment: Performance Schema
Transactions: NO
XA: NO
Savepoints: NO
...
Движок хранения PERFORMANCE_SCHEMA работает с таблицами в базе данных performance_schema. Вы можете сделать performance_schema базой данных по умолчанию, чтобы ссылки на ее таблицы не нужно было квалифицировать именем базы данных:
mysql> USE performance_schema;
Таблицы схемы производительности хранятся в базе данных performance_schema. Информацию о структуре этой базы данных и ее таблиц можно получить, как и для любой другой базы данных, путем выборки из базы данных INFORMATION_SCHEMA или с помощью операторов SHOW. Например, используйте любой из этих операторов, чтобы увидеть, какие таблицы схемы производительности существуют:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'performance_schema';
+------------------------------------------------------+
| TABLE_NAME |
+------------------------------------------------------+
| accounts |
| cond_instances |
...
| events_stages_current |
| events_stages_history |
| events_stages_history_long |
| events_stages_summary_by_account_by_event_name |
| events_stages_summary_by_host_by_event_name |
| events_stages_summary_by_thread_by_event_name |
| events_stages_summary_by_user_by_event_name |
| events_stages_summary_global_by_event_name |
| events_statements_current |
| events_statements_history |
| events_statements_history_long |
...
| file_instances |
| file_summary_by_event_name |
| file_summary_by_instance |
| host_cache |
| hosts |
| memory_summary_by_account_by_event_name |
| memory_summary_by_host_by_event_name |
| memory_summary_by_thread_by_event_name |
| memory_summary_by_user_by_event_name |
| memory_summary_global_by_event_name |
| metadata_locks |
| mutex_instances |
| objects_summary_global_by_type |
| performance_timers |
| replication_connection_configuration |
| replication_connection_status |
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| rwlock_instances |
| session_account_connect_attrs |
| session_connect_attrs |
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| setup_timers |
| socket_instances |
| socket_summary_by_event_name |
| socket_summary_by_instance |
| table_handles |
| table_io_waits_summary_by_index_usage |
| table_io_waits_summary_by_table |
| table_lock_waits_summary_by_table |
| threads |
| users |
+------------------------------------------------------+
mysql> SHOW TABLES FROM performance_schema;
+------------------------------------------------------+
| Tables_in_performance_schema |
+------------------------------------------------------+
| accounts |
| cond_instances |
| events_stages_current |
| events_stages_history |
| events_stages_history_long |
...
Количество таблиц схемы производительности увеличивается со временем по мере реализации дополнительных инструментов.
Имя базы данных performance_schema и имена таблиц в ней написаны строчными буквами. Запросы должны указывать имена в нижнем регистре.
Чтобы увидеть структуру отдельных таблиц, используйте SHOW CREATE TABLE:
mysql> SHOW CREATE TABLE performance_schema.setup_consumers\G
*************************** 1. row ***************************
Table: setup_consumers
Create Table: CREATE TABLE `setup_consumers` (
`NAME` varchar(64) NOT NULL,
`ENABLED` enum('YES','NO') NOT NULL
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
Структура таблиц также доступна путем выборки из таблиц, таких как INFORMATION_SCHEMA.COLUMNS, или с помощью операторов, таких как SHOW
COLUMNS.
Таблицы в базе данных performance_schema можно сгруппировать по типу информации в них: текущие события, истории и сводки событий, экземпляры объектов и информация о настройке (конфигурации). Следующие примеры иллюстрируют несколько способов использования этих таблиц. Подробную информацию о таблицах каждой группы см. в Разделе 25.12, «Описание таблиц схемы производительности».
Изначально не все инструменты и потребители включены, поэтому схема производительности не собирает все события. Чтобы включить все эти инструменты и включить временные метки событий, выполните два оператора (количество строк может отличаться в зависимости от версии MySQL):
mysql> UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES';
Query OK, 560 rows affected (0.04 sec)
mysql> UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES';
Query OK, 10 rows affected (0.00 sec)
Чтобы увидеть, что в данный момент делает сервер, изучите таблицу events_waits_current. Она содержит по одной строке на каждый поток, показывая последнее отслеженное событие каждого потока:
mysql> SELECT *
FROM performance_schema.events_waits_current\G
*************************** 1. row ***************************
THREAD_ID: 0
EVENT_ID: 5523
END_EVENT_ID: 5523
EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK::mutex
SOURCE: thr_lock.c:525
TIMER_START: 201660494489586
TIMER_END: 201660494576112
TIMER_WAIT: 86526
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 142270668
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: 0
...
Это событие указывает, что поток 0 ожидал 86 526 пикосекунд для получения блокировки на THR_LOCK::mutex, мьютексе в подсистеме mysys. Первые несколько столбцов предоставляют следующую информацию:
Столбцы ID указывают, из какого потока происходит событие и номер события.
EVENT_NAMEуказывает, что было инструментировано, аSOURCEуказывает, какой исходный файл содержит инструментированный код.Столбцы таймера показывают, когда началось и остановилось событие, и сколько времени это заняло. Если событие все еще в процессе, значения
TIMER_ENDиTIMER_WAITравныNULL. Значения таймеров приблизительны и выражены в пикосекундах. Дополнительную информацию о таймерах и сборе временных меток событий см. в Разделе 25.4.1, «Временные метки событий схемы производительности».
Таблицы истории содержат те же строки, что и таблица текущих событий, но содержат больше строк и показывают, чем сервер занимался «недавно», а не «сейчас». Таблицы events_waits_history и events_waits_history_long содержат последние 10 событий на поток и последние 10 000 событий соответственно. Например, чтобы увидеть информацию о недавних событиях, произведенных потоком 13, выполните следующее:
mysql> SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT
FROM performance_schema.events_waits_history
WHERE THREAD_ID = 13
ORDER BY EVENT_ID;
+----------+-----------------------------------------+------------+
| EVENT_ID | EVENT_NAME | TIMER_WAIT |
+----------+-----------------------------------------+------------+
| 86 | wait/synch/mutex/mysys/THR_LOCK::mutex | 686322 |
| 87 | wait/synch/mutex/mysys/THR_LOCK_malloc | 320535 |
| 88 | wait/synch/mutex/mysys/THR_LOCK_malloc | 339390 |
| 89 | wait/synch/mutex/mysys/THR_LOCK_malloc | 377100 |
| 90 | wait/synch/mutex/sql/LOCK_plugin | 614673 |
| 91 | wait/synch/mutex/sql/LOCK_open | 659925 |
| 92 | wait/synch/mutex/sql/THD::LOCK_thd_data | 494001 |
| 93 | wait/synch/mutex/mysys/THR_LOCK_malloc | 222489 |
| 94 | wait/synch/mutex/mysys/THR_LOCK_malloc | 214947 |
| 95 | wait/synch/mutex/mysys/LOCK_alarm | 312993 |
+----------+-----------------------------------------+------------+
По мере добавления новых событий в таблицу истории старые события удаляются, если таблица заполнена.
Таблицы сводок предоставляют агрегированную информацию обо всех событиях за определенный период времени. Таблицы этой группы суммируют данные событий по-разному. Чтобы увидеть, какие инструменты были выполнены чаще всего или потребовали наибольшего времени ожидания, отсортируйте таблицу events_waits_summary_global_by_event_name по столбцу COUNT_STAR или SUM_TIMER_WAIT, которые соответствуют значениям COUNT(*) или SUM(TIMER_WAIT) соответственно, рассчитанным по всем событиям:
mysql> SELECT EVENT_NAME, COUNT_STAR
FROM performance_schema.events_waits_summary_global_by_event_name
ORDER BY COUNT_STAR DESC LIMIT 10;
+---------------------------------------------------+------------+
| EVENT_NAME | COUNT_STAR |
+---------------------------------------------------+------------+
| wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 |
| wait/io/file/sql/FRM | 452 |
| wait/synch/mutex/sql/LOCK_plugin | 337 |
| wait/synch/mutex/mysys/THR_LOCK_open | 187 |
| wait/synch/mutex/mysys/LOCK_alarm | 147 |
| wait/synch/mutex/sql/THD::LOCK_thd_data | 115 |
| wait/io/file/myisam/kfile | 102 |
| wait/synch/mutex/sql/LOCK_global_system_variables | 89 |
| wait/synch/mutex/mysys/THR_LOCK::mutex | 89 |
| wait/synch/mutex/sql/LOCK_open | 88 |
+---------------------------------------------------+------------+
mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT
FROM performance_schema.events_waits_summary_global_by_event_name
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
+----------------------------------------+----------------+
| EVENT_NAME | SUM_TIMER_WAIT |
+----------------------------------------+----------------+
| wait/io/file/sql/MYSQL_LOG | 1599816582 |
| wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 |
| wait/io/file/sql/binlog_index | 1385291934 |
| wait/io/file/sql/FRM | 1292823243 |
| wait/io/file/myisam/kfile | 411193611 |
| wait/io/file/myisam/dfile | 322401645 |
| wait/synch/mutex/mysys/LOCK_alarm | 145126935 |
| wait/io/file/sql/casetest | 104324715 |
| wait/synch/mutex/sql/LOCK_plugin | 86027823 |
| wait/io/file/sql/pid | 72591750 |
+----------------------------------------+----------------+
Эти результаты показывают, что мьютекс THR_LOCK_malloc «активный», как с точки зрения частоты его использования, так и с точки зрения времени ожидания потоков при попытке его получения.
Мьютекс THR_LOCK_malloc используется только в отладочных сборках. В производственных сборках он не активный, так как его не существует.
Таблицы экземпляров документируют типы объектов, которые были инструментированы. Инструментированный объект, когда используется сервером, генерирует событие. Эти таблицы предоставляют имена событий и поясняющие заметки или сведения о статусе. Например, таблица file_instances перечисляет экземпляры инструментов для операций ввода-вывода файлов и соответствующие файлы:
mysql> SELECT *
FROM performance_schema.file_instances\G
*************************** 1. row ***************************
FILE_NAME: /opt/mysql-log/60500/binlog.000007
EVENT_NAME: wait/io/file/sql/binlog
OPEN_COUNT: 0
*************************** 2. row ***************************
FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
*************************** 3. row ***************************
FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
...
Таблицы настроек используются для настройки и отображения характеристик мониторинга. Например, setup_instruments перечисляет набор инструментов, для которых можно собирать события, и показывает, какие из них включены:
mysql> SELECT * FROM performance_schema.setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| stage/sql/end | NO | NO |
| stage/sql/executing | NO | NO |
| stage/sql/init | NO | NO |
| stage/sql/insert | NO | NO |
...
| statement/sql/load | YES | YES |
| statement/sql/grant | YES | YES |
| statement/sql/check | YES | YES |
| statement/sql/flush | YES | YES |
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...
Чтобы понять, как интерпретировать имена инструментов, см. Раздел 25.6, «Конвенции именования инструментов схемы производительности».
Чтобы контролировать сбор событий для инструмента, установите его значение ENABLED в YES или NO. Например:
mysql> UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO'
WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';
Схема производительности использует собранные события для обновления таблиц в базе данных performance_schema, которые действуют как «потребители» информации о событиях. Таблица setup_consumers перечисляет доступных потребителей и какие из них включены:
mysql> SELECT * FROM performance_schema.setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+----------------------------------+---------+
Чтобы контролировать, сохраняет ли схема производительности потребителя в качестве пункта назначения для информации о событиях, установите его значение ENABLED.
Для получения дополнительной информации о таблицах настроек и о том, как использовать их для управления сбором событий, см. Раздел 25.4.2, «Фильтрация событий схемы производительности».
Есть некоторые таблицы общего назначения, которые не относятся ни к одной из предыдущих групп. Например, performance_timers перечисляет доступные таймеры событий и их характеристики. Дополнительную информацию о таймерах см. в Разделе 25.4.1, «Временные метки событий схемы производительности».
© 2025 Oracle
Licensed under the GPLv2 License.