Проблемы с подключением базы данных Azure SQL - слишком много соединений?

У меня есть сайт, который представляет собой белую метку (несколько версий одного и того же сайта), которую я недавно запустил. Пока еще не так много трафика - в основном боты, но, возможно, 800 пользователей в день. Он размещен на Azure с базой данных Azure в дополнение к админ-панели, расположенной на не-лазурном сервере. Оба узла подключаются к одной базе данных Azure. Есть также некоторые рабочие роли, выполняемые для обработки данных - 99% времени, когда они ничего не делают, но регулярно проверяют.

Я всегда испытывал случайные ошибки, которые длились несколько секунд, а затем снова ок, например:

При получении результатов с сервера произошла ошибка транспортного уровня. (поставщик: поставщик TCP, ошибка: 0 - существующее соединение было принудительно закрыто удаленным хостом.)

Сегодня утром у нас была более серьезная проблема. Это началось с:

System.ComponentModel.Win32Exception: существующее соединение было принудительно закрыто удаленным хостом

Это произошло, в то время как боты (Google, Baidu, AhrefsBot и Wiseguys.nl) индексировали сайт. У меня есть одна или несколько ошибок. Затем я получил:

System.Data.SqlClient.SqlException: служба столкнулась с ошибкой обработки вашего запроса. Пожалуйста, попробуйте еще раз. Код ошибки 40143. Сильная ошибка произошла в текущей команде. Результаты, если таковые имеются, должны быть отброшены.

Это было во время фазы ExecuteReader.

Через 10 минут возникла настоящая проблема - это означало, что никто не смог войти в интерфейс администратора, но веб-сайт Azure появился нормально, когда я его протестировал, хотя боты все еще вызывали ошибки. Проблема заключалась в следующем:

System.ComponentModel.Win32Exception: время ожидания ожидания

Это продолжалось со случайными подключениями, работающими в течение и около часа. Затем я столкнулся с другой проблемой:

System.Data.SqlClient.SqlException: Идентификатор ресурса: 1. Предел запроса для базы данных равен 180 и достигнут. См. 'http://go.microsoft.com/fwlink/?LinkId=267637' для помощи.

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

SELECT * FROM sys.dm_exec_requests

Он возвращал только 1 или 2 запроса, когда я запускал его снова и снова.

Итак, мои вопросы: 1) Кто-нибудь еще испытывает относительно регулярное (один раз, возможно, два раза в день) временное отключение от сервера, размещенного на Azure? 2) Указывает ли перечисленный выше перечень событий на конкретную проблему? Все это могло произойти, когда в систему вошло множество админов. 3) Как лучше отлаживать количество запросов к базе данных, когда я получаю сообщение с лимитом 180?

Спасибо заранее.

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ответ 3

При получении результатов с сервера произошла ошибка транспортного уровня. (поставщик: поставщик TCP, ошибка: 0 - существующее соединение было принудительно закрыто удаленным хостом.)

System.ComponentModel.Win32Exception: существующее соединение было принудительно закрыто удаленным хостом

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

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