Огляд сценаріїв продуктивності

  • 5 хв.

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

Загальні сценарії продуктивності

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

схему запуску та очікування.

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

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

    Azure Monitor має інтегровані показники для перегляду використання ресурсів для Azure SQL. Ви також можете налаштувати оповіщення, щоб шукати умови використання ресурсів.

  • sys.dm_db_resource_stats

    Для бази даних Azure SQL можна переглянути цей DMV, щоб переглянути використання ресурсів ЦП, пам'яті та вводу-виводу для розгортання бази даних. Цей DMV робить знімок цих даних кожні 15 секунд.

  • sys.server_resource_stats

    Цей DMV працює так само, як sys.dm_db_resource_stats, але використовується для перегляду використання ресурсів для керованого екземпляра SQL для ЦП, пам'яті та вводу-виводу. Цей DMV також робить знімок кожні 15 секунд.

  • sys.dm_user_db_resource_governance

    Для бази даних Azure SQL цей DMV повертає фактичну конфігурацію та параметри потужності, які використовуються механізмами керування ресурсами в поточній базі даних або еластичному пулі.

  • sys.dm_instance_resource_governance

    Для керованого екземпляра Azure SQL цей DMV повертає такі самі відомості, як sys.dm_user_db_resource_governance, але для поточного керованого екземпляра SQL.

Біг

Якщо ви визначили, що проблема полягає у високому використанні ЦП, це називається запущеним сценарієм. Запущений сценарій може включати запити, які споживають ресурси за допомогою компіляції або виконання. Для подальшого аналізу скористайтеся наведеними нижче засобами.

  • Сховище запитів

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

  • sys.dm_exec_requests

    Використовуйте цей DMV в Azure SQL, щоб отримати знімок стану активних запитів. Знайдіть запити зі станом RUNNABLE та типом очікування SOS_SCHEDULER_YIELD, щоб дізнатися, чи достатньо ресурсів ЦП.

  • sys.dm_exec_query_stats

    Цей DMV можна використовувати так само, як сховище запитів, щоб знайти найпопулярніші запити, які споживають ресурси. Вона доступна лише для кешованих планів запитів, тоді як сховище запитів забезпечує постійний історичний запис про продуктивність. Цей DMV також дає змогу знайти план запитів для кешованого запиту.

  • sys.dm_exec_procedure_stats

    Цей DMV надає такі відомості, як sys.dm_exec_query_stats, за винятком відомостей про продуктивність, які можна переглянути на рівні збереженої процедури.

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

Очікує

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

  • Очікування вводу-виводу
  • Очікування блокування
  • Очікування засувки
  • Обмеження буферних пулів
  • Гранти пам'яті
  • Планування виселення кеша

Щоб виконати аналіз сценаріїв очікування, зазвичай потрібно переглянути такі засоби:

  • sys.dm_os_wait_stats

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

  • sys.dm_exec_requests

    Скористайтеся цим DMV, щоб знайти певні типи очікування для активних запитів, щоб дізнатися, на який ресурс вони очікують. Це може бути стандартний сценарій блокування, який очікує на блокування від інших користувачів.

  • sys.dm_os_waiting_tasks

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

  • Сховище запитів

    Сховище запитів надає звіти та подання каталогу, які показують агрегацію верхнього очікування виконання плану запитів. Важливо знати, що очікування ЦП еквівалентне проблемі.

Сценарії, характерні для Azure SQL

Існують деякі сценарії продуктивності, як запущені, так і очікування, характерні для Azure SQL. До них належать керування журналами, робочі обмеження, очікування, що виникають для рівнів служби "Критичний бізнес" і очікування, специфічні для розгортання Hyperscale.

Керування журналами

Azure SQL може використовувати керування швидкістю журналу, щоб забезпечити обмеження на використання журналу транзакцій. Це застосування може знадобитися, щоб забезпечити обмеження ресурсів і виконати обіцяну SLA. Керування журналами може відображатися в таких типах очікування:

  • LOG_RATE_GOVERNOR: очікування бази даних Azure SQL
  • POOL_LOG_RATE_GOVERNOR: чекає еластичних басейнів
  • INSTANCE_LOG_GOVERNOR: очікується керований екземпляр Azure SQL
  • HADR_THROTTLE_LOG_RATE*: очікування затримки критичного бізнесу та геовідповіді

Робочі обмеження

SQL Server використовує робочий пул потоків, але має обмеження на максимальну кількість працівників. Програми з великою кількістю одночасних користувачів можуть наближатися до робочих обмежень, застосованих для бази даних Azure SQL і керованого екземпляра SQL:

  • База даних Azure SQL має обмеження на основі рівня та розміру служби. Якщо перевищено це обмеження, з'явиться новий запит.
  • У поточний час керований екземпляр SQL використовує max worker threads, тому працівники, які минули це обмеження, можуть бачити THREADPOOL очікування.

Очікування щодо критичних факторів hadR для бізнесу

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

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Незважаючи на те, що ці очікування можуть не сповільнити роботу програми, ви, можливо, не очікуєте побачити їх. Зазвичай вони стосуються використання групи доступності Always On. Критично важливі для бізнесу рівні використовують технологію групи доступності для впровадження SLA та функцій доступності рівня служби "Критично важливий для бізнесу", тому ці типи очікування очікуються. Довгий час очікування може вказувати на вузьке місце, наприклад затримку вводу-виводу або репліку позаду.

Гіпер-смуга

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

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