Почему моя база данных Azure SQL (SQL Server) перегружается вводом-выводом данных в течение периодов времени? [закрыто]

Я использую базу данных SQL Azure под редакцией S2 (50 DTU). При обычном использовании сервера обычно висит около 10% DTU. Однако этот сервер регулярно переходит в состояние, когда он будет отправлять использование DTU базы данных на 85-90% в течение нескольких часов. Затем внезапно он возвращается к нормальному использованию 10%.

В этом перегруженном состоянии запросы к серверу из приложения по-прежнему работают быстро.

Я могу масштабировать сервер из S2 => что угодно (например, S3) => S2, и он, похоже, очищает любое состояние, в котором он находится. Но через несколько часов он снова повторяет тот же цикл перегруженных состояний. Еще одна странная вещь, которую я заметил, заключается в том, что, если я запускаю этот сервер на плане S3 (100 DTU) 24/7, я не наблюдал такого поведения. Кажется, это происходит только тогда, когда я сократил базу данных до плана S2 (50 DTU). На плане S3 я всегда сижу на 5-10% использования DTU. Очевидно, недостаточно используется.

Я зарегистрировался в отчетах SQL-запросов Azure в поисках мошеннических запросов, но на самом деле я не вижу ничего необычного, и он показывает мои запросы с использованием ресурсов, как и следовало ожидать.

Как мы можем видеть здесь, все использование исходит от Data IO. Если я изменю отчет о производительности здесь, чтобы показать самые высокие запросы ввода-вывода данных по MAX, мы увидим это:

Глядя на эти длительные запросы, кажется, указывает на обновления статистики. На самом деле ничего не работает из моего приложения. Например, запрос 16302 там показывает:

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM [dbo].[Cipher] TABLESAMPLE SYSTEM (1.250395e+000 PERCENT) WITH (READUNCOMMITTED) ) AS _MS_UPDSTATS_TBL_HELPER ORDER BY [SC0], [SC1], [SC2], [SB0000] ) AS _MS_UPDSTATS_TBL  OPTION (MAXDOP 16)

Но опять же, отчет также показывает, что эти запросы используют только небольшой процент использования ввода-вывода данных на сервере (<4%). Я также запускаю обновления статистики (и перестройки индекса) для всей базы данных на еженедельной основе в рамках регулярного обслуживания.

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

Как мы видим, на самом деле нет запросов, сообщающих о значительном использовании ввода-вывода данных.

Кроме того, я побежал sp_who2и sp_whoisaciveв базе данных и на самом деле не вижу ничего выпрыгивая у меня (хотя я признаю , что я не являюсь экспертом с помощью этих инструментов).

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

Учитывая, что во время пика (-ов) ваша активность в журнале минимальна, мы можем предположить, что DUI не происходит (или много).

Вы упоминаете в один момент, что всплеск не влияет на производительность, а в другом случае это влияет. Что он?

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

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

Попробуйте следующий запрос во время всплеска:

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    s.status,
    c.auth_scheme, s.host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
ORDER BY c.connect_time ASC

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

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

CREATE DATABASE Database1_copy AS COPY OF Database1 ( EDITION = 'basic' );