Упражнение — масштабирование производительности рабочей нагрузки

• 10 мин

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

Все скрипты этого упражнения можно найти в папке 04-Performance\monitor_and_scale в репозитории GitHub, который вы клонировали или скачанный ZIP-файл.

Увеличение производительности SQL Azure с помощью масштабирования

Чтобы масштабировать производительность при возникновении проблемы недостатка ресурсов ЦП, необходимо установить, какие имеются варианты, а затем перейти к масштабированию ЦП с помощью предоставленных интерфейсов для SQL Azure.

1. Выбор вариантов масштабирования производительности. Так как рабочая нагрузка привязана к ЦП, одним из способов повышения производительности является увеличение емкости ЦП или скорости. Чтобы получить больше ресурсов ЦП, пользователю SQL Server нужно будет перейти на другой компьютер или перенастроить виртуальную машину. В некоторых случаях даже администратор SQL Server может не иметь разрешения на внесение этих изменений в масштабирование. Процесс может занять некоторое время и даже потребовать миграции базы данных.

   Для Azure можно использовать ALTER DATABASEAzure CLI или портал Azure для увеличения емкости ЦП без миграции базы данных в рамках пользователя.

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

   

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

   

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

4. Для этого упражнения, чтобы мы могли увидеть адекватные различия в отчетах, необходимо сначала очистить хранилище запросов. В СРЕДЕ SQL Server Management Studio (SSMS) выберите базу данных AdventureWorks и используйте меню "Открыть>файл".> Откройте скрипт flushhquerystore.sql в SSMS в контексте базы данных AdventureWorks. Окно редактора запросов должно выглядеть как в следующем тексте:

   EXEC sp_query_store_flush_db;
   

   Выберите "Выполнить" , чтобы запустить этот пакет T-SQL.

   Примечание.

   При выполнении предыдущего запроса выполняется очистка части хранилище запросов данных на диск.

5. Откройте сценарий get_service_objective.sql в SSMS. Окно редактора запросов должно выглядеть как в следующем тексте:

   SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
   FROM sys.dm_user_db_resource_governance;
   GO
   SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
   GO
   

   Это метод для определения уровня служб с помощью T-SQL. Цены или уровень служб также называют целью служб. Выберите "Выполнить" , чтобы запустить пакеты T-SQL.

   Для текущего развертывания базы данных SQL Azure результаты должны выглядеть, как на следующем рисунке:

   

   Обратите внимание на термин slo_name, который также используется для цели служб. SLO означает Service Level Objective — целевой уровень обслуживания.

   Различные slo_name значения не документируются, но можно увидеть из строкового значения, которое эта база данных использует уровень служб общего назначения с двумя виртуальными ядрами:

   Примечание.

   SQLDB_OP_... — это строка, используемая для уровня "Критически важный для бизнеса".

   При просмотре документации по ALTER DATABASE обратите внимание на возможность выбора целевого развертывания SQL Server для получения правильных параметров синтаксиса. Выберите Одна база данных/эластичный пул базы данных SQL, чтобы просмотреть параметры базы данных SQL Azure. Чтобы сопоставить масштабирование вычислений, найденное на портале, необходима цель служб 'GP_Gen5_8'.

6. Измените цель служб для базы данных, чтобы увеличить количество ЦП. Откройте скрипт modify_service_objective.sql в SSMS и запустите пакет T-SQL. Окно редактора запросов должно выглядеть как в следующем тексте:

   ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
   

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

   

7. В обозревателе объектов в папке Системные базы данных щелкните правой кнопкой мыши базу данных master и выберите Создать запрос. Выполните этот запрос в окне редактора запросов SSMS:

   SELECT * FROM sys.dm_operation_status;
   

   Это еще один способ отслеживать ход изменения цели служб для базы данных SQL Azure. Это динамическое административное представление предоставляет историю изменений цели обслуживания в базе данных с помощью инструкции ALTER DATABASE. Оно показывает активный ход выполнения изменения.

   Ниже приведен пример выходных данных этого динамического административного представления в формате таблицы после выполнения приведенной выше инструкции ALTER DATABASE:

   Пункт меню	Значение
   session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
   resource_type	0
   resource_type_desc	База данных
   major_resource_id	AdventureWorks
   minor_resource_id
   Операция	ALTER DATABASE
   state	1
   state_desc	IN_PROGRESS
   percent_complete	0
   Error_Code	0
   error_desc
   error_severity	0
   error_state	0
   start_time	[дата и время]
   last_modify_time	[дата и время]

   Во время изменения цели обслуживания запросы к базе данных разрешаются до тех пор, пока не будет реализовано окончательное изменение. Приложение не может подключиться в течение очень короткого периода времени. Для Управляемого экземпляра SQL Azure при изменении уровня разрешены запросы и подключения, но запрещены все операции с базами данных, например создание новых баз данных. В этих случаях вы получите следующее сообщение об ошибке: "Не удалось завершить операцию, так как изменение уровня служб выполняется для управляемого экземпляра "[сервер]. Дождитесь завершения операции и повторите попытку".

8. После этого используйте приведенные выше запросы из get_service_objective.sql в SSMS, чтобы убедиться, что новая цель службы или уровень служб 8 виртуальных ядер ввели в силу.

Запуск рабочей нагрузки после увеличения масштаба

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

1. Теперь, когда масштабирование завершено, нам нужно определить, выполняется ли рабочая нагрузка быстрее и уменьшилось ли время ожидания ресурсов ЦП. Снова запустите рабочую нагрузку с помощью команды sqlworkload.cmd , которую вы выполнили в предыдущем упражнении.

2. С помощью SSMS выполните тот же запрос, что и в первом упражнении этого модуля, чтобы просмотреть результаты сценария dmdbresourcestats.sql:

   SELECT * FROM sys.dm_db_resource_stats;
   

   Вы должны увидеть, что среднее использование ресурсов ЦП снизилось по сравнению с почти 100 % использованием в предыдущем упражнении. Обычно отображается sys.dm_db_resource_stats один час действия. Изменение размера базы данных приводит sys.dm_db_resource_stats к сбросу.

3. С помощью SSMS выполните тот же запрос, что и в первом упражнении этого модуля, чтобы просмотреть результаты скрипта dmexecrequests.sql.

   SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
   FROM sys.dm_exec_requests er
   INNER JOIN sys.dm_exec_sessions es
   ON er.session_id = es.session_id
   AND es.is_user_process = 1;
   

   Вы увидите, что больше запросов имеют состояние RUNNING. Это означает, что наши рабочие роли получают больше ресурсов ЦП для выполнения.

4. Отследите новую длительность рабочей нагрузки. Длительность рабочей нагрузки из sqlworkload.cmd теперь должна быть гораздо меньше, примерно 25–30 секунд.

Отслеживание отчетов хранилища запросов

Рассмотрим те же отчеты хранилища запросов, что и в предыдущем упражнении.

1. Используя те же методы, что и в первом упражнении этого модуля, ознакомьтесь с отчетом Топ ресурсоемких запросов из SSMS:

   

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

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

   

3. Вы можете закрыть все отчеты и окна редактора запросов. Оставьте подключение SSMS, так как вам потребуется в следующем упражнении.

Наблюдение за изменениями с помощью Метрик Azure

1. Перейдите в базу данных AdventureWorks в портал Azure и просмотрите вкладку "Мониторинг" на панели обзора еще раз для использования вычислений:

   

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

2. Эта диаграмма может в некоторой степени вводить в заблуждение. В меню "Мониторинг" используйте метрики, а затем задайте для метрики ограничение ЦП. Сравнительная диаграмма ЦП выглядит примерно следующим образом:

   

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