Изучение сценариев производительности

  • 5 мин

Чтобы решить, как использовать средства и возможности производительности, важно изучить производительность SQL Azure с помощью сценариев.

Общие сведения о сценариях производительности

Распространенный метод устранения неполадок с производительностью SQL Server — это проверить, является ли проблема производительности выполняющейся (высокая загрузка ЦП) или ожидающей (ожидание ресурса). На следующей схеме показано дерево принятия решений, позволяющее определить, касается ли проблема производительности SQL Server выполнения или ожидания, а также то, как использовать средства оценки производительности для поиска причины и решения.

Схема выполнения и ожидания.

Сначала рассмотрим общее использование ресурсов. Для стандартного развертывания SQL Server можно использовать такие средства, как Монитор производительности в Windows или вверху в Linux. Для SQL Azure можно использовать следующие методы:

  • Портал Azure/PowerShell/оповещения

    Azure Monitor содержит интегрированные метрики для просмотра использования ресурсов в SQL Azure. Также можно настроить оповещения для поиска условий использования ресурсов.

  • sys.dm_db_resource_stats

    При использовании базы данных SQL Azure можно просмотреть это динамическое административное представление, чтобы увидеть использование ресурсов ЦП, памяти и операций ввода-вывода для развертывания базы данных. Это динамическое административное представление создает моментальный снимок вышеперечисленных данных каждые 15 секунд.

  • sys.server_resource_stats

    Это динамическое административное представление ведет себя так же, как sys.dm_db_resource_stats, но оно используется, чтобы просматривать использование ресурсов ЦП, памяти и операций ввода-вывода для Управляемого экземпляра SQL. Это динамическое административное представление также создает моментальный снимок каждые 15 секунд.

  • sys.dm_user_db_resource_governance

    Для Базы данных SQL Azure это динамическое административное представление возвращает фактические параметры конфигурации и емкости, используемые механизмами управления ресурсами в текущей базе данных или эластичном пуле.

  • sys.dm_instance_resource_governance

    Для Управляемый экземпляр SQL Azure этот dmV возвращает аналогичную информацию, как sys.dm_user_db_resource_governanceи для текущей Управляемый экземпляр SQL.

Бег

Если вы определили, что проблема состоит в высокой загрузке ЦП, это называется сценарием выполнения. Выполняемый сценарий может включать в себя запросы, которые потребляют ресурсы при компиляции или выполнении. Для дальнейшего анализа используйте следующие средства:

  • Хранилище запросов

    Используйте отчеты о топе ресурсоемких запросов в SSMS, представлениях каталога хранилища запросов или анализе производительности запросов на портале Azure (только для базы данных SQL Azure), чтобы определить, какие запросы потребляют больше всего ресурсов ЦП.

  • sys.dm_exec_requests

    Используйте это динамическое административное представление в SQL Azure для получения моментального снимка состояния активных запросов. Найдите запросы с состоянием RUNNABLE ожидания и типом ожидания SOS_SCHEDULER_YIELD , чтобы узнать, достаточно ли у вас достаточно ресурсов ЦП.

  • sys.dm_exec_query_stats

    Это динамическое административное представление можно использовать в хранилище запросов для поиска наиболее ресурсоемких запросов. Он доступен только для планов запросов, которые кэшируются, в то время как хранилище запросов предоставляет постоянную историческую запись производительности. Это динамическое административное представление также позволяет найти план запроса для кэшированного запроса.

  • sys.dm_exec_procedure_stats

    Это динамическое административное представление предоставляет ту же информацию, что и sys.dm_exec_query_stats, за исключением того, что сведения о производительности можно просмотреть на уровне хранимой процедуры.

    После определения того, какой запрос или запросы потребляют больше всего ресурсов, может потребоваться проверить, достаточно ли ресурсов ЦП для вашей рабочей нагрузки. Вы можете выполнять отладку планов запросов с помощью таких инструментов, как упрощенное профилирование запросов, инструкции SET, хранилище запросов или трассировка расширенных событий.

Ожидание

Если проблема не заключается в высоком использовании ресурсов ЦП, она может быть связана с ожиданием ресурса. Сценарии, включающие в себя ожидание ресурсов:

  • ожидания ввода-вывода;
  • ожидания блокировок;
  • ожиданий кратковременных блокировок;
  • ограничения буферного пула;
  • временно предоставляемые буферы памяти;
  • вытеснение кэша планов.

Чтобы выполнить анализ сценариев ожидания, обычно вы изучите следующие средства:

  • sys.dm_os_wait_stats

    Используйте это динамическое административное представление для просмотра самых частых типов ожидания для базы данных или экземпляра. Это поможет вам узнать, какие действия следует предпринять в зависимости от самых частых типов ожидания.

  • sys.dm_exec_requests

    Используйте это динамическое административное представление, чтобы найти определенные типы ожидания для активных запросов, чтобы узнать, какой ресурс они ожидают. Это может быть стандартным сценарием блокировки, ожидающим блокировок от других пользователей.

  • sys.dm_os_waiting_tasks

    С помощью этого DMV можно определить типы ожидания для конкретной задачи в определенном запросе, выполняющемся в данный момент, чтобы, возможно, понять, почему это занимает больше времени, чем обычно. sys.dm_os_waiting_tasks содержит статистику ожидания в реальном времени, которая sys.dm_os_wait_stats агрегатов с течением времени.

  • Хранилище запросов

    Хранилище запросов представляет отчеты и представления каталогов, которые показывают агрегат самых частых ожиданий выполнения плана запроса. Важно знать, что ожидание ЦП эквивалентно выполнению проблемы.

Сценарии, относящиеся к SQL Azure

Существуют некоторые сценарии производительности, выполняющиеся и ожидающие, которые относятся только к SQL Azure. К ним относятся управление журналами, пределы рабочих ролей, ожидание на уровне служб "Критически важный для бизнеса" и ожидание развертывания на уровне "Гипермасштабирование".

Управление журналами

SQL Azure может использовать управление скоростью ведением журнала, чтобы применять ограничения ресурсов на использование журнала транзакций. Это применение может потребоваться для обеспечения ограничения ресурсов и выполнения обещанного соглашения об уровне обслуживания. Управление журналами можно наблюдать в следующих типах ожидания:

  • LOG_RATE_GOVERNOR: ожидает База данных SQL Azure
  • POOL_LOG_RATE_GOVERNOR: ожидание эластичных пулов
  • INSTANCE_LOG_GOVERNOR: ожидает Управляемый экземпляр SQL Azure
  • HADR_THROTTLE_LOG_RATE*: ожидает задержки критически важный для бизнеса и георепликации

Ограничения работников

SQL Server использует рабочий пул потоков, но имеет ограничения на максимальное количество рабочих ролей. Приложения с большим количеством одновременных пользователей могут приблизиться к ограничениям рабочей роли, применяемым для База данных SQL Azure и Управляемый экземпляр SQL:

  • Ограничения базы данных SQL Azure основаны на уровне служб и размере. Если превысить это ограничение, новый запрос получит сообщение об ошибке.
  • В настоящее время Управляемый экземпляр SQL используетсяmax worker threads, поэтому работники, прошедшие это ограничение, могут видеть THREADPOOL ожидания.

Ожидания HADR на уровне "Критически важный для бизнеса"

Если вы используете уровень служб "Критически важный для бизнеса", вы можете неожиданно обнаружить следующие типы ожидания:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Несмотря на то, что эти ожидания могут не замедлить работу приложения, вы можете не ожидать их появления. Обычно они относятся к использованию группы доступности Always On. Уровень "Критически важный для бизнеса" использует технологию группы доступности для реализации функций соглашения об уровне обслуживания и доступности, поэтому эти типы ожидания могут встречаться. Длительное время ожидания может указывать на узкие места, такие как задержка ввода-вывода или отставание реплики.

Гипермасштаб

Архитектура гипермасштабирования может привести к некоторым уникальным типам ожидания, которые префиксированы RBIO (возможное указание системы управления журналами). Кроме того, динамические административные представления, представления каталога и расширенные события расширяются для отображения метрик для чтения серверов страниц.

В следующем упражнении вы узнаете, как отслеживать и решать проблему производительности для SQL Azure с помощью средств и знаний, полученных в этом уроке.