(Первоначально опубликовано на DBA.StackExchange.com, но закрыто, надеюсь, более актуально здесь.)
Александр и Грозный, Ужасный, Нехороший, Очень Плохой... резервные копии.
Установка:
у меня есть локальная Стандартный выпуск SQL Server 2016 экземпляр, работающий на виртуальная машина от ВМВар.
@@Версия:
Microsoft SQL Server 2016 (SP2-CU17) (KB5001092) — 13.0.5888.11 (X64)
19 марта 2021 г., 19:41:38 Авторское право (c) Стандарт корпорации Майкрософт
Edition (64-разрядная версия) в Windows Server 2016 Datacenter 10.0 (сборка
14393: ) (гипервизор)
Сам сервер в настоящее время выделен 8 виртуальных процессоров, имеет 32 ГБ памяти, и все диски - это NVM которые обойти 1 ГБ/сек ввода/вывода. Сами базы живут на диске G:, а резервные копии отдельно хранятся на диске P:. Общий размер всех баз данных составляет около 500 ГБ (до сжатия в сами файлы резервных копий).
План обслуживания запускается один раз ночью (около 22:30) для создания полной резервной копии каждой базы данных на сервере. На сервере не работает ничего необычного, и в это время, в частности, ничего не работает. План электропитания на сервере установлен на «Сбалансированный» (а для «Отключить жесткий диск через» установлено значение 0 минут, то есть никогда не выключайте его).
Что случилось:
За последний год или около того общее время выполнения задания плана обслуживания заняло около 15 минут. минуты Всего завершить. С прошлой недели он увеличился примерно в 40 раз, примерно в 15 раз. часы завершить.
Единственное, что я знаю об изменении в тот же день, когда план обслуживания замедлился, это следующие обновления Windows, которые были установлены на машине до запуска плана обслуживания:
- KB890830
- КБ5004752
- КБ5005043
- VMWare — SCSIAадаптер — 1.3.17.0
- VMWare — дисплей — 8.17.2.14
У нас также есть еще один экземпляр SQL Server с аналогичной подготовкой на другой виртуальной машине, которая подверглась тем же обновлениям Windows, а затем впоследствии также испытала более медленное резервное копирование. Думая, что обновления Windows были непосредственной причиной, мы полностью откатили их, и план обслуживания резервных копий все равно работает очень медленно. Как ни странно, восстановление резервных копий для данной базы данных происходит очень быстро и использует почти все 1 ГБ/с ввода-вывода на NVM.
Что я пробовал:
Используя sp_whoisactive от Adam Mechanic, я определил, что типы последнего ожидания процессов резервного копирования всегда указывают на проблему с производительностью диска.я всегда вижу РЕЗЕРВНЫЙ БУФЕР и РЕЗЕРВНОЕ КОПИРОВАНИЕ типы ожидания, в дополнение к ASYNC_IO_COMPLETION:
При просмотре Монитора ресурсов на самом сервере во время резервного копирования раздел Дисковый ввод-вывод показывает, что общий объем ввода-вывода составляет всего около 14 МБ/с (максимальное, что я когда-либо видел с момента возникновения этой проблемы, это 30 МБ/сек):
Наткнувшись на это полезное Статья Брента Озара об использовании DiskSpd, я попробовал запустить его сам с аналогичными параметрами (только уменьшив количество потоков до 8, так как у меня на сервере 8 виртуальных процессоров и установив запись на 50%). Это точная команда diskspd.exe -b2M -d60 -o32 -h -L -t8 -W -w50 "C:\Users\...\Desktop\Microsoft DiskSpd\Test\LargeFile.txt". Я использовал текстовый файл, созданный вручную, размером чуть менее 1 ГБ. Я считаю, что измеренный ввод-вывод кажется нормальным, но задержки диска показывали нелепые цифры:
Результаты DiskSpd кажутся буквально невероятными. После дальнейшего чтения я наткнулся на запрос Пола Рэндалла, который возвращает показатели задержки диска для каждой базы данных. Это были результаты:
Наихудшая задержка записи составила 63 миллисекунды, а наихудшая задержка чтения — 6 миллисекунд, так что это кажется большим отличием от DiskSpd и не кажется достаточно ужасным, чтобы быть основной причиной моей проблемы. Продолжая перекрестную проверку, я запустил несколько счетчиков PerfMon на самом сервере. эта статья Майкрософт, и это были результаты:
Здесь нет ничего экстраординарного, максимальное значение всех счетчиков, которые я измерил, было 0,007 (что, я полагаю, составляет миллисекунды?). Наконец, моя группа по инфраструктуре проверила показатели задержки диска, которые VMWare регистрировала во время задания резервного копирования, и вот результаты:
Похоже, что в худшем случае около полуночи произошел всплеск задержки примерно на 200 миллисекунд, а максимальная скорость ввода-вывода составила 600 КБ/с (чего я не совсем понимаю, поскольку монитор ресурсов показывает, что резервные копии по крайней мере используют около 14 МБ/с ввода/вывода).
Другие вещи, которые я пробовал:
Я только что попытался восстановить одну из больших баз данных (около 250 ГБ), и восстановление заняло всего около 8 минут. Затем я попытался запустить DBCC CHECKDB на нем, и это заняло в общей сложности 16 минут (не уверен, что это нормально), но Resource Monitor показал аналогичные проблемы с вводом-выводом (максимальная скорость ввода-вывода, которую он когда-либо использовал, составляла 100 МБ / с), при этом больше ничего не работало:
Вот результаты sp_whoisactive при первом запуске DBCC CHECKDB а затем, когда он был выполнен на 5%, обратите внимание, что расчетное оставшееся время увеличилось примерно на 5 минут, даже после того, как он был выполнен уже на 5%.
Начинать:
5% Готово:
Я предполагаю, что это нормально, так как это всего лишь оценка, и 16 минут не кажутся слишком плохими для базы данных на 250 ГБ (хотя я не уверен, что это нормально), но снова ввод-вывод был максимальным только в около 10% возможностей диска, при этом на сервере или экземпляре SQL больше ничего не работает.
Это результаты из DBCC CHECKDB, об ошибках не сообщается.
Я также испытывал странные проблемы с медлительностью с СОКРАЩАТЬ команда. я просто пытался СОКРАЩАТЬ база данных, в которой было 5% места для выпуска (около 14 ГБ). На выполнение 90% задания ушло всего около 1 минуты. СОКРАЩАТЬ:
Примерно через 5 минут он все еще зависает на том же проценте завершения, а мои резервные копии журнала транзакций (которые обычно заканчиваются через 1-2 секунды) находятся в состоянии спора в течение примерно 30 секунд:
15 минут спустя и СОКРАЩАТЬ только что заканчивается, в то время как резервные копии журнала транзакций все еще обсуждаются в течение примерно 6 минут и завершены только на 50%. Я считаю, что они сразу же закончили сразу после этого, так как СОКРАЩАТЬ законченный. Все это время Монитор ресурсов показывал, что ввод-вывод все еще отстой:
Затем я получил ошибку с СОКРАЩАТЬ команда, когда она закончилась:
я повторил попытку СОКРАЩАТЬ снова, и это привело к тому же результату, что и выше.
Затем я попытался вручную создать резервную копию T-SQL в файл на диске P:, и это работало медленно, как и задание резервного копирования плана обслуживания:
В итоге я отменил его примерно через 3 минуты, и он сразу же откатился.
Резюме:
Так совпало, что задание плана обслуживания резервного копирования становилось примерно в 40 раз медленнее (с 15 минут до 15 часов) каждую ночь сразу после установки обновлений Windows. Откат этих обновлений Windows не решил проблему. Типы ожидания SQL Server, Resource Monitor и Microsoft DiskSpd указывают на проблему с диском (в частности, с вводом-выводом), но все другие измерения из запроса Пола Рэндалла, PerfMon и журналов VMWare не сообщают о каких-либо проблемах с дисками. Восстановление резервных копий для конкретной базы данных выполняется быстро и использует почти все операции ввода-вывода со скоростью 1 ГБ/с. Я чешу голову...
