20.15. Используя Схему Производительности, чтобы Диагностировать проблемы

Схема Производительности является инструментом, чтобы помочь DBA сделать производительность, настраивающуюся, проводя реальные измерения вместо "произвольных предположений." Этот раздел демонстрирует некоторые способы использовать Схему Производительности с этой целью. Обсуждение здесь полагается на использование фильтрации событий, которая описывается в Разделе 20.2.3.2, "Фильтрация событий Схемы Производительности".

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

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

При каждой итерации, выводе Схемы Производительности, особенно events_waits_history_long таблица, будет содержать всё меньше и меньше "шум", вызванный незначащими инструментами, и данный, что у этой таблицы есть фиксированный размер, будет содержать все больше данных, относящихся к анализу проблемы под рукой.

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

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

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