Производительность миграции: базовые показатели производительности при миграции из SQL Server в управляемый экземпляр SQL Azure

  • Статья

Применимо к:Управляемому экземпляру SQL Azure

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

Создание базовых показателей

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

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

Следующие ресурсы помогут определить базовые показатели производительности.

  • Мониторинг использования ЦП
  • Мониторинг использования памяти и определение объема памяти, используемой различными компонентами, такими как буферный пул, кэш планов, пул columnstore, выполняющаяся в памяти OLTP и т. д. Кроме того, нужно найти средние и пиковые значения счетчика производительности памяти ожидаемого времени существования страницы.
  • Мониторинг потребления дисковых операций ввода-вывода на исходном экземпляре SQL Server с помощью представления sys.dm_io_virtual_file_stats или счетчиков производительности.
  • Мониторинг рабочей нагрузки и производительность запросов путем исследования динамических административных представлений (или хранилища запросов, если вы переходите с SQL Server 2016 или более поздних версий). Определите среднюю длительность и потребление ресурсов ЦП наиболее важных запросов в вашей рабочей нагрузке.

Все проблемы производительности на исходном сервере SQL должны быть устранены до миграции. Перенос известных проблем в любую новую систему может привести к непредвиденным результатам и обесценить любое сравнение производительности.

Сравнение производительности

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

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

Сравнение производительности может привести к следующим результатам.

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

  • Большинство параметров производительности и запросов в рабочей нагрузке выполняются как ожидалось, за некоторыми исключениями, в которых наблюдается снижение производительности. В этом случае определите различия и их важность. Если вы обнаружите некоторые важные запросы с ухудшенной производительностью, выясните, не изменились ли базовые планы SQL, и не достигнуты ли ограничения ресурсов запросов. Можно смягчить это ухудшение, применив в критических запросах некоторые указания (например, изменение уровня совместимости, оценщик унаследованной кратности) напрямую или с помощью структур плана. Убедитесь, что статистика и индексы актуальны и эквивалентны в обеих средах.

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

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

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

Мониторинг производительности

Управляемый экземпляр SQL предоставляет расширенные инструменты для мониторинга и устранения неполадок, и вам следует использовать их для мониторинга производительности вашего экземпляра. Далее приведены некоторые ключевые метрики для мониторинга.

  • Потребление ресурсов ЦП в экземпляре позволяет определить, соответствует ли количество подготовленных к работе виртуальных ядер вашей рабочей нагрузке.
  • Ожидаемое время существования страницы в управляемом экземпляре позволяет определить, требуется ли дополнительная память.
  • Статистика, такая как INSTANCE_LOG_GOVERNOR или PAGEIOLATCH, выявляет проблемы дисковых операций ввода-вывода, особенно на уровне обслуживания общего назначения, где может потребоваться предварительное выделение файлов для повышения производительности операций ввода-вывода.

Рекомендации

При сравнении производительности учитывайте следующие аспекты.

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

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

  • Существуют ключевые различия сред, которые могут вызвать разницу в производительности между управляемым экземпляром и SQL Server. Определите риски, относящиеся к вашей среде, которые могут вносить вклад в снижение производительности.

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

Дальнейшие действия

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