29.7 Мониторинг состояния схемы производительности
Для схемы производительности существуют несколько переменных состояния:
mysql> SHOW STATUS LIKE 'perf%';
+-----------------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------------+-------+
| Performance_schema_accounts_lost | 0 |
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_digest_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_hosts_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_memory_classes_lost | 0 |
| Performance_schema_metadata_lock_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_nested_statement_lost | 0 |
| Performance_schema_program_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_session_connect_attrs_lost | 0 |
| Performance_schema_socket_classes_lost | 0 |
| Performance_schema_socket_instances_lost | 0 |
| Performance_schema_stage_classes_lost | 0 |
| Performance_schema_statement_classes_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Performance_schema_users_lost | 0 |
+-----------------------------------------------+-------+
Переменные состояния схемы производительности предоставляют информацию об инструментах, которые не удалось загрузить или создать из-за ограничений памяти. Имена этих переменных имеют несколько форм:
Performance_schema_показывает, сколько инструментов типаxxx_classes_lostxxxне удалось загрузить.Performance_schema_показывает, сколько экземпляров объектов типаxxx_instances_lostxxxне удалось создать.Performance_schema_показывает, сколько экземпляров объектов типаxxx_handles_lostxxxне удалось открыть.Performance_schema_locker_lostпоказывает, сколько событий «“потеряны”» или не были записаны.
Например, если мьютекс инструментирован в исходном коде сервера, но сервер не может выделить память для инструментирования во время выполнения, он увеличивает значение Performance_schema_mutex_classes_lost. Мьютекс по-прежнему функционирует как объект синхронизации (то есть сервер продолжает работать нормально), но данные производительности для него не собираются. Если инструмент можно выделить, его можно использовать для инициализации инструментированных экземпляров мьютексов. Для мьютекса типа «синглтон», такого как глобальный мьютекс, существует только один экземпляр. Другие мьютексы имеют по одному экземпляру на соединение или на страницу в различных кэшах и буферах данных, поэтому количество экземпляров со временем меняется. Увеличение максимального числа соединений или максимального размера некоторых буферов увеличивает максимальное количество экземпляров, которые могут быть выделены одновременно. Если сервер не может создать определённый инструментированный экземпляр мьютекса, он увеличивает Performance_schema_mutex_instances_lost.
Предположим, что выполняются следующие условия:
Сервер был запущен с опцией
--performance_schema_max_mutex_classes=200и, таким образом, имеет место для 200 инструментов мьютексов.Уже загружено 150 инструментов мьютексов.
Плагин под названием
plugin_aсодержит 40 инструментов мьютексов.Плагин под названием
plugin_bсодержит 20 инструментов мьютексов.
Сервер выделяет инструменты мьютексов для плагинов в зависимости от их потребностей и доступности, как показано в следующей последовательности операторов:
INSTALL PLUGIN plugin_a
Теперь сервер имеет 150 + 40 = 190 инструментов мьютексов.
UNINSTALL PLUGIN plugin_a;
Сервер по-прежнему имеет 190 инструментов. Все исторические данные, сгенерированные кодом плагина, по-прежнему доступны, но новые события для инструментов не собираются.
INSTALL PLUGIN plugin_a;
Сервер обнаруживает, что 40 инструментов уже определены, поэтому новые инструменты не создаются, а ранее назначенные внутренние буферы памяти повторно используются. Сервер по-прежнему имеет 190 инструментов.
INSTALL PLUGIN plugin_b;
Сервер имеет место для 200-190 = 10 инструментов (в данном случае, классов мьютексов) и видит, что плагин содержит 20 новых инструментов. 10 инструментов загружаются, а 10 отбрасываются или «“потеряны”». Performance_schema_mutex_classes_lost указывает количество потерянных инструментов (классов мьютексов):
mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| Performance_schema_mutex_classes_lost | 10 |
+---------------------------------------+-------+
1 row in set (0.10 sec)
Инструментарий по-прежнему работает и собирает (частичные) данные для plugin_b.
Когда сервер не может создать инструмент мьютекса, возникают эти результаты:
Строка для инструмента не вставляется в таблицу
setup_instruments.Performance_schema_mutex_classes_lostувеличивается на 1.Performance_schema_mutex_instances_lostне изменяется. (Когда инструмент мьютекса не создаётся, его нельзя использовать для создания инструментированных экземпляров мьютексов позже.)
Описанный шаблон применим ко всем типам инструментов, а не только к мьютексам.
Значение Performance_schema_mutex_classes_lost больше нуля может возникнуть в двух случаях:
Чтобы сохранить несколько байтов памяти, вы запускаете сервер с
--performance_schema_max_mutex_classes=, гдеNNменьше значения по умолчанию. Значение по умолчанию выбрано так, чтобы загрузить все плагины, предоставляемые в дистрибутиве MySQL, но его можно уменьшить, если некоторые плагины никогда не загружаются. Например, вы можете выбрать, не загружать некоторые из систем хранения данных в дистрибутиве.-
Вы загружаете сторонний плагин, который инструментирован для схемы производительности, но не учитываете потребности плагина в памяти при запуске сервера. Поскольку он сторонний, потребление памяти инструментирования этого плагина не учитывается при выборе значения по умолчанию для
performance_schema_max_mutex_classes.Если у сервера недостаточно ресурсов для инструментов плагина и вы не выделяете больше ресурсов явно с помощью
--performance_schema_max_mutex_classes=, загрузка плагина приводит к голоданию инструментов.N
Если выбранное значение для performance_schema_max_mutex_classes слишком мало, в журнале ошибок не сообщается об ошибке, и во время выполнения не происходит сбоя. Однако содержимое таблиц в базе данных performance_schema пропускает события. Performance_schema_mutex_classes_lost переменная состояния является единственным видимым признаком того, что некоторые события были внутренне потеряны из-за невозможности создания инструментов.
Если инструмент не потерян, он известен схеме производительности и используется при инструментировании экземпляров. Например, wait/synch/mutex/sql/LOCK_delete — это имя инструмента мьютекса в таблице setup_instruments. Этот единственный инструмент используется при создании мьютекса в коде (в THD::LOCK_delete), однако при работе сервера требуется много экземпляров мьютекса. В этом случае LOCK_delete — это мьютекс на подключение (THD), поэтому если сервер имеет 1000 подключений, есть 1000 потоков и 1000 инструментированных LOCK_delete экземпляров мьютекса (THD::LOCK_delete).
Если у сервера нет места для всех этих 1000 инструментированных мьютексов (экземпляров), некоторые мьютексы создаются с инструментированием, а некоторые — без него. Если сервер может создать только 800 экземпляров, 200 экземпляров теряются. Сервер продолжает работу, но увеличивает Performance_schema_mutex_instances_lost на 200, чтобы указать, что экземпляры не могли быть созданы.
Значение Performance_schema_mutex_instances_lost больше нуля может возникать, когда код инициализирует больше мьютексов во время выполнения, чем было выделено для --performance_schema_max_mutex_instances=.N
В заключение, если SHOW STATUS LIKE
'perf%' говорит, что ничего не потеряно (все значения равны нулю), данные схемы производительности точные и на них можно положиться. Если что-то было потеряно, данные неполные, и схема производительности не смогла записать всё из-за недостатка выделенной памяти. В этом случае конкретная переменная Performance_schema_ указывает проблемную область.xxx_lost
В некоторых случаях может быть уместно вызвать преднамеренное голодание инструментов. Например, если вам не важны данные производительности для ввода-вывода файлов, вы можете запустить сервер со всеми параметрами схемы производительности, относящимися к вводу-выводу файлов, установленным в 0. Память не выделяется для классов, экземпляров или дескрипторов, связанных с файлами, и все события файлов теряются.
Используйте SHOW ENGINE
PERFORMANCE_SCHEMA STATUS для проверки внутренней работы кода схемы производительности:
mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G
...
*************************** 3. row ***************************
Type: performance_schema
Name: events_waits_history.size
Status: 76
*************************** 4. row ***************************
Type: performance_schema
Name: events_waits_history.count
Status: 10000
*************************** 5. row ***************************
Type: performance_schema
Name: events_waits_history.memory
Status: 760000
...
*************************** 57. row ***************************
Type: performance_schema
Name: performance_schema.memory
Status: 26459600
...
Этот запрос предназначен для того, чтобы помочь администратору базы данных понять, как различные параметры схемы производительности влияют на потребности в памяти. Для описания значений полей см. Раздел 15.7.7.16, «Запрос SHOW ENGINE».
© 2025 Oracle
Licensed under the GPLv2 License.