Spec-Zone .ru
спецификации, руководства, описания, API

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

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

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

  1. Выполните вариант использования.

  2. Используя таблицы Схемы Производительности, проанализируйте первопричину проблемы производительности. Этот анализ положится в большой степени на постфильтрацию.

  3. Для проблемных областей, которые исключаются, отключите соответствующие инструменты. Например, если анализ показывает, что проблема не связывается с файловым вводом-выводом в определенном механизме хранения, отключите инструменты файлового ввода-вывода для того механизма. Затем усеките историю и сводные таблицы, чтобы удалить ранее собранные события.

  4. Повторите процесс в шаге 1.

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

    При каждой итерации исследование должно вести ближе и ближе к первопричине проблемы, поскольку отношение "сигнала/шума" улучшится, делая легче анализ.

  5. Как только первопричина узкого места производительности идентифицируется, примите соответствующие меры по ликвидации последствий, такие как:

    • Настройте параметры сервера (размеры кэша, память, и т.д).

    • Настройте запрос при записи этого по-другому,

    • Настройте схему базы данных (таблицы, индексирует, и т.д).

    • Настройте код (это применяется к механизму хранения или разработчикам сервера только).

  6. Начните снова в шаге 1, видеть эффекты изменений на производительности.

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

  1. Предположите, что распараллеливают 1, застревает, ожидая взаимного исключения.

  2. Можно определить то, чего ожидает поток:

    SELECT * FROM events_waits_current WHERE THREAD_ID = thread_1;

    Скажите, что результат запроса идентифицирует это, поток ожидает взаимного исключения A, найденный в events_waits_current.OBJECT_INSTANCE_BEGIN.

  3. Можно определить, какой поток содержит взаимное исключение A:

    SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;

    Скажите, что результат запроса идентифицирует это, это - поток 2 взаимных исключения содержания A, как найдено в mutex_instances.LOCKED_BY_THREAD_ID.

  4. Можно видеть то, что распараллеливает 2, делает:

    SELECT * FROM events_waits_current WHERE THREAD_ID = thread_2;