29.19 Using the Performance Schema to Diagnose Problems — MySQL 9.2

29.19 Использование Performance Schema для диагностики проблем

Performance Schema — инструмент, который помогает администраторам баз данных в настройке производительности, используя реальные измерения вместо «догадок». В этом разделе показаны способы использования Performance Schema для этой цели. Здесь обсуждение опирается на использование фильтрации событий, описанной в разделе 29.4.2 «Фильтрация событий Performance Schema».

Следующий пример демонстрирует методологию анализа повторяющейся проблемы, например, расследования узких мест производительности. Для начала вам нужно иметь повторяющийся сценарий использования, где производительность считается «слишком медленной» и требует оптимизации, а также включить всю инструментацию (без предварительной фильтрации).

Запустите сценарий использования.
Используя таблицы Performance Schema, проанализируйте причину проблемы с производительностью. Этот анализ сильно зависит от постфильтрации.
Для областей проблемы, которые исключены, отключите соответствующие инструменты. Например, если анализ показывает, что проблема не связана с вводом-выводом файлов в определенном движке хранения, отключите инструменты ввода-вывода файлов для этого движка. Затем обнулите таблицы истории и сводки, чтобы удалить ранее собранные события.
Повторите процесс на шаге 1.

На каждом шаге вывод Performance Schema, особенно таблица events_waits_history_long, содержит все меньше «шума», вызванного несущественными инструментами, и, учитывая, что эта таблица имеет фиксированный размер, содержит все больше данных, относящихся к анализу рассматриваемой проблемы.

На каждом шаге исследование должно все ближе подводить к корню проблемы, поскольку соотношение «сигнал/шум» улучшается, что упрощает анализ.
После определения причины узкого места производительности примените соответствующие корректирующие действия, такие как:
- Настройка параметров сервера (размеры кэша, память и т. д.).
- Настройка запроса путем его переписывания.
- Настройка схемы базы данных (таблицы, индексы и т. д.).
- Настройка кода (это относится только к разработчикам движка хранения или сервера).
Начните снова с шага 1, чтобы увидеть влияние изменений на производительность.

Столбцы mutex_instances.LOCKED_BY_THREAD_ID и rwlock_instances.WRITE_LOCKED_BY_THREAD_ID крайне важны для расследования узких мест производительности или тупиков. Это становится возможным благодаря инструментации Performance Schema следующим образом:

Предположим, что поток 1 застрял в ожидании мьютекса.
Вы можете определить, чего ждет поток:
```
SELECT * FROM performance_schema.events_waits_current
WHERE THREAD_ID = thread_1;
```
Допустим, результат запроса показывает, что поток ждет мьютекса A, найденного в events_waits_current.OBJECT_INSTANCE_BEGIN.
Вы можете определить, какой поток удерживает мьютекс A:
```
SELECT * FROM performance_schema.mutex_instances
WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
```
Допустим, результат запроса показывает, что это поток 2, удерживающий мьютекс A, как указано в mutex_instances.LOCKED_BY_THREAD_ID.

Вы можете увидеть, что делает поток 2:

SELECT * FROM performance_schema.events_waits_current
WHERE THREAD_ID = thread_2;