Мониторинг и устранение проблем с производительностью

  • 10 мин

Мониторинг и устранение проблем — ключевой элемент обеспечения стабильной производительности. В SQL Azure имеются те же средства и функции мониторинга и устранения проблем, что и в SQL Server, а также дополнительные возможности. Сюда входят такие функции, как динамические административные представления (DMV), расширенные события и Azure Monitor. Также важно узнать, как использовать эти средства и возможности в различных сценариях производительности для SQL Azure. Эти сценарии включают высокую загрузку ЦП или ожидание ресурса.

Средства и возможности для мониторинга производительности

SQL Azure предоставляет возможности мониторинга и устранения неполадок в экосистеме Azure, а также знакомые средства, которые входят в состав SQL Server. Мы кратко рассмотрим эти преимущества в следующих разделах.

Azure Monitor

Azure Monitor является частью экосистемы Azure, и SQL Azure интегрирована с ним для поддержки метрик, оповещений и журналов Azure. Вы можете визуализировать данные Azure Monitor в портал Azure, а приложения могут получить доступ к этим данным с помощью Центры событий Azure или API. Как и Windows Монитор производительности, Azure Monitor помогает получить доступ к метрикам использования ресурсов для SQL Azure без использования средств SQL Server.

Динамические административные представления (DMV)

Sql Azure предоставляет почти ту же инфраструктуру DMV, что и SQL Server, с несколькими различиями. Динамические административные представления являются важнейшим элементом мониторинга производительности, так как позволяют просматривать ключевые данные о производительности SQL Server с помощью стандартных запросов T-SQL. Например, вы можете просмотреть такие сведения, как активные запросы, использование ресурсов, планы запросов и типы ожидания ресурсов. Дополнительные сведения о динамических административных представлениях с помощью SQL Azure см. далее в этом уроке.

Расширенные события

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

Упрощенное профилирование запросов

Упрощенное профилирование — это расширенный метод для устранения неполадок в сценариях, требующих получения фактического плана выполнения для запросов в полете и запросов с высоким уровнем ценности. Из-за низкой нагрузки любой сервер, который еще не привязан к ЦП, может непрерывно выполнять упрощенную профилирование, и разрешить специалистам по базам данных в любое время выполнять любое выполнение; Например, с помощью монитора действий в SQL Server Management Studio (SSMS) или непосредственного sys.dm_exec_query_profiles запроса или sys.dm_exec_query_statistics_xml.

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

Возможности отладки плана запроса

В некоторых ситуациях могут потребоваться дополнительные сведения о производительности запросов для отдельной инструкции T-SQL. Эти сведения могут предоставлять инструкции SET T-SQL, такие как SHOWPLAN и STATISTICS. Они полностью поддерживаются в SQL Azure, равно как и в SQL Server.

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

Хранилище запросов — это запись истории выполнения запросов, хранящаяся в пользовательской базе данных. Хранилище запросов включено по умолчанию для SQL Azure и используется для предоставления таких возможностей, как автоматическое исправление плана и автоматическая настройка. Отчеты SQL Server Management Studio (SSMS) для хранилища доступны в SQL Azure. Используйте эти отчеты, чтобы искать самые ресурсоемкие запросы, включая различия в планах запросов и типы с наибольшим ожиданием для рассмотрения сценариев ожидания ресурсов.

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

Для базы данных SQL Azure вы можете просматривать интегрированные сведения о производительности хранилища запросов на портале Azure с помощью визуализаций. Таким образом, вы можете увидеть некоторые из таких же сведений для хранилище запросов, как и с клиентским инструментом, таким как SSMS. Используйте параметры "Обзор производительности" и "Анализ производительности запросов" в портал Azure.

Сведения о динамических административных представлениях

Динамические административные представления (DMV) много лет были решающей силой в отслеживании и устранении неполадок производительности SQL Server. Общие динамические административные представления для SQL Server доступны в SQL Azure. Также добавлены новые специально для Azure.

Управляемый экземпляр SQL Azure

Все динамические административные представления для SQL Server доступны и в Управляемом экземпляре SQL. Динамические административные представления ключей, такие как sys.dm_exec_requests и sys.dm_os_wait_stats часто используются для проверки производительности запросов.

Системное sys.server_resource_stats представление зависит от Управляемый экземпляр SQL Azure и показывает использование исторических ресурсов. Это полезное средство для просмотра использования ресурсов, так как у вас нет прямого доступа к средствам операционной системы, таким как Монитор производительности.

База данных SQL Azure

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

Динамическое sys.dm_db_resource_stats административное представление зависит от База данных SQL Azure, и его можно использовать для просмотра журнала использования ресурсов для базы данных. Используйте это динамическое административное представление так же, как sys.server_resource_stats, для Управляемого экземпляра.

Динамическое sys.elastic_pool_resource_stats административное представление аналогично sys.dm_db_resource_stats, но его можно использовать для просмотра использования ресурсов для баз данных эластичного пула.

Необходимые динамические административные представления

Для решения определенных сценариев производительности для SQL Azure необходимы следующие динамические административные представления:

  • sys.dm_io_virtual_file_stats необходимо, так как у вас нет прямого доступа к метрикам операционной системы по производительности ввода-вывода на файл.
  • sys.dm_os_performance_counters, позволяющее просмотреть распространенные метрики производительности SQL Server, доступно для базы данных SQL Azure и Управляемого экземпляра SQL. Используйте это динамическое представление для просмотра сведений о счетчике производительности SQL Server, которые обычно доступны в Монитор производительности.
  • sys.dm_instance_resource_governance позволяет просматривать ограничения ресурсов для Управляемого экземпляра. Вы можете просматривать эти сведения, чтобы увидеть, каковы будут ожидаемые ограничения ресурсов без использования портала Azure.
  • sys.dm_user_db_resource_governance позволяет просматривать общие ограничения ресурсов в зависимости от варианта развертывания, уровня служб и размера для развертывания базы данных SQL Azure. Вы можете просматривать эти сведения, чтобы увидеть, каковы будут ожидаемые ограничения ресурсов без использования портала Azure.

Динамические административные представления для более подробной аналитики

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

  • sys.dm_user_db_resource_governance_internal (только для Управляемого экземпляра SQL)
  • sys.dm_resource_governor_resource_pools_history_ex
  • sys.dm_resource_governor_workload_groups_history_ex

Сведения расширенных событий

Расширенные события — это механизм трассировки для SQL Server. Расширенные события для SQL Azure основаны на ядре SQL Server и, следовательно, почти одинаковы для AZURE SQL с несколькими заметными различиями. Эти отличия рассматриваются в следующих разделах.

Расширенные события для базы данных SQL Azure

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

  • Поддерживаются наиболее часто используемые события и действия.
  • Поддерживаются целевые объекты file, ring_buffer и counter.
  • Целевые объекты file поддерживаются в хранилище BLOB-объектов Azure, так как у вас нет доступа к базовым дискам операционной системы.

Для создания и запуска сеансов можно использовать SSMS или T-SQL. Вы можете использовать SSMS для просмотра целевых данных сеанса расширенных событий или системной функции sys.fn_xe_file_target_read_file.

Примечание.

Невозможно использовать SSMS для просмотра активных данных для База данных SQL Azure.

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

Расширенные события для Управляемого экземпляра SQL Azure

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

  • Поддерживаются все события, целевые объекты и действия.
  • Целевые объекты file поддерживаются в хранилище BLOB-объектов Azure, так как у вас нет доступа к базовым дискам операционной системы.
  • Для Управляемого экземпляра SQL добавляются некоторые конкретные события, чтобы обеспечить трассировку событий, относящихся к управлению и выполнению экземпляра.

Для создания и запуска сеансов можно использовать SSMS или T-SQL. Вы можете использовать SSMS для просмотра целевых данных сеанса расширенных событий или системной функции sys.fn_xe_file_target_read_file. Возможность SSMS просматривать динамические данные поддерживается для SQL Server и Управляемый экземпляр SQL Azure.

Сценарии производительности для SQL Azure

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

Обычные сценарии производительности

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

Diagram of running versus waiting.

Рассмотрим подробнее каждый аспект этой схемы.

Выполнение и ожидание

Сначала рассмотрим общее использование ресурсов. Для стандартного развертывания 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

    С помощью этого динамического административного представления можно найти типы ожидания для конкретной задачи для конкретного запроса, выполняющегося в настоящее время, возможно, чтобы узнать, почему это занимает больше времени, чем обычно. 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 с помощью средств и знаний, полученных в этом уроке.