Azure SQL DTU подпрыгивает и застревает

Question

У меня были проблемы с Azure SQL, часто увеличивая DTU в случайные моменты времени без изменений в загрузке запроса. Я обычно вижу большой скачок в dataIO, за которым вскоре следует скачок в процессоре. Затем DataIO стихнет, но загрузка процессора, по-видимому, застрянет, а время отклика станет чрезмерным до того момента, когда код запроса начинает истекать. Единственный способ, который я нашел, чтобы исправить проблему - это увеличить или уменьшить ее, разрешить, а затем вернуться к исходной настройке.

Мы используем размер S4, однако достаточно S2, за исключением периодов обслуживания центра обработки данных. Как я упоминал, когда он «застревает», я уменьшаю его до S2, позволяю ему стабилизироваться, а затем возвращаюсь к S4, и все возвращается к нормальной жизни. Мы также запускаем 4 реплики, доступные только для чтения, и код переключается между репликами, когда обнаруживает проблему, которая дает нам время, чтобы выполнить трюк масштабирования и вернуть все в нормальное состояние. Это хорошо работает до тех пор, пока чтение / запись не переместится вбок, и тогда некуда будет переключиться.

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

Azure SQL 24-часовой график, работает нормально, DTU прыгает и застревает, затем после масштабирования возвращается в нормальное состояние

Кто-нибудь знает, что может быть причиной этого и что на самом деле делает масштабирование на уровне сервера?

EDIT:

Эти события обычно начинаются с высокого, но не обязательно максимального ввода / вывода данных, но затем они прекращаются, а затем происходит высокая загрузка ЦП, которая просто продолжается без какой-либо другой ненормальной активности, чтобы объяснить это. После прочтения комментариев я только что упомянул, что когда мы переносим нагрузку с одного вторичного сервера, испытывающего эту проблему, на другой, в исходной базе данных все падает до нуля, но тот, на который мы переключаемся, только увеличивается до нашего обычного уровня. 5% - 8% использование DTU. если мы затем переместим трафик обратно к первому, первый снова «застрянет», а другой снова опустится до использования перед переключением. Он ведет себя так, как будто настройка масштаба выпала из списка, но нет никаких признаков того, что это произошло на портале.

Что касается перестроений индекса, мы автоматизировали код, выполняемый в функции, запускаемой таймером Azure, которая проверяет фрагментацию по разному индексу каждую ночь (в ранние утренние часы), и при достаточной фрагментации запускается перестройка. Самая длинная перестройка длится около часа, и для прохождения всех индексов требуется около 17 дней. Если их не нужно восстанавливать, он перейдет к следующему.

Answer 1

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

Вы можете увидеть тайм-ауты подключения с помощью следующего запроса:

select * 
from sys.event_log 
where event_type <> 'connection_successful' and
start_time >= CAST(FLOOR(CAST(getdate() AS float)) AS DATETIME)
order by start_time desc

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

SELECT     
(COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'CPU Fit Percent',
(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Log Write Fit Percent',
(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Physical Data Read Fit Percent'
FROM sys.dm_db_resource_stats
--service level objective (SLO) of 99.9% <= go to next tier

Когда avg_log_write_percent имеет значение 100% или около 100%, происходит удушение. Попробуйте реализовать масштабирование до премиальных уровней перед запуском интенсивных рабочих нагрузок ввода-вывода.

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

Answer 2

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