25.19 Using the Performance Schema to Diagnose Problems — MySQL 5.7

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

25.19.1 Профилирование запросов с помощью Performance Schema

Performance Schema — это инструмент, помогающий администратору базы данных (DBA) проводить настройку производительности, используя реальные измерения, а не «догадки». Этот раздел демонстрирует несколько способов использования Performance Schema для этой цели. В данном обсуждении используются фильтры событий, описание которых представлено в разделе 25.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;