Тайм-аут SQL Server в течение 2 минут при масштабировании моего приложения ASP.NET Core в AWS ECS
У меня возникла проблема с моим приложением ASP.NET Core 6, работающим на AWS ECS (Fargate).
Мое приложение использует клиент SQL для выполнения запросов SQL. Когда, например, запущено 10 экземпляров, все работает хорошо.
Но чтобы правильно масштабировать мой сервис в соответствии с объемом трафика, у меня есть работа, которая запускает и масштабирует мой сервис ECS. Например, если я ожидаю гораздо большего трафика, задание увеличит количество задач с 10 до 15.
Проблема возникает после развертывания Blue/Green. Как только мои новые задачи выполняются (проверка работоспособности в порядке), балансировщик нагрузки приложения отправляет трафик на новые задачи. Но в течение первых двух минут после того, как новые задачи начали получать трафик, я сталкиваюсь с таймаутами SQL. По истечении этого времени тайм-ауты исчезают, и новые задачи должным образом обрабатывают SQL-запросы.
Вот логи моих новых задач:
Я не понимаю, почему я сталкиваюсь с тайм-аутами SQL, но только в начале выполнения моего приложения.
Что я уже пытался сделать:
- Указание порта SQL Server в строке подключения
- Установка атрибута
Min Pool Sizeна 100 в моей строке подключения - Открытие первого
SqlDbConnectionв моемProgram.cs, чтобы разрешить доменное имя моего прослушивателя SQL Server.
Что я могу сделать, чтобы больше не получать эти таймауты?
У меня есть две среды: одна на экземпляре EC2, а другая на RDS. И я столкнулся с этой проблемой на обоих
Похоже, среда для этих задач не готова полностью до 2 минут? Например, ваша сеть. Разве проверка работоспособности не должна включать в себя сетевые данные?
Как я уже говорил, я пытался подключиться к экземпляру своей базы данных при запуске приложения (используя SqlDbConnection), и он работает нормально. Итак, с точки зрения сети кажется, что все настроено для правильного взаимодействия с базой данных.
Итак, у вас при запуске есть рабочее соединение, но потом оно перестает работать, как только вы включаете маршрутизацию? Звучит подозрительно
Да, поэтому я ничего не понимаю из того, что происходит
Что такое SqlDbConnection? Учитывая сообщения об ошибках на вашем снимке экрана (которые, кстати, должны были быть включены в виде текста, а не снимков экрана), это звучит как сторонний класс-оболочка для устаревших System.Data.SqlClient объектов , которые не получали обновлений функций с 2019 года . Поскольку вы больше не используете .NET Framework, почему вы не используете более современные и активно разрабатываемые Microsoft.Data.SqlClient классы?
Мы используем внутреннюю оболочку, которая используется и является общей для приложений, работающих на .NET Framework и .NET Core. Это основная причина. Я перешел на Microsoft.Data.SqlClient, но это ничего не меняет. Но мне удалось потенциально решить проблему, выполнив базовую команду SQL при запуске приложения (SELECT 1;). Кажется, что выполнение первого запроса перед получением трафика (тысячи HTTP-запросов, то есть тысячи SQL-запросов) решает проблему: я больше не получаю никаких тайм-аутов.
@AlwaysLearning which should have been included as text, by the way, not screen shots извини, приятель, я не трачу всю свою жизнь на StackOverflow, поэтому не знаком со всеми лучшими практиками. В будущем я буду включать журналы в виде текста.
Ответы 1
Кажется, что получение трафика без хотя бы одного выполнения SQL-запроса приводит к этим тайм-аутам.
Выполнение первого запроса SQL во время запуска приложения решило проблему.
Что я предлагаю:
- Интегрируйте проверку работоспособности базы данных в свои проверки работоспособности (в моем случае это не то, что я хочу).
- Или выполните простой SQL-запрос во время запуска приложения
SELECT 1;
Я выпустил исправление в производство, и у меня больше нет тайм-аутов.
Если у кого-нибудь есть объяснение, почему это так работает? (даже если да, я согласен, что это грязное решение)
«Похоже, что получение трафика без хотя бы одного выполнения SQL-запроса приводит к этим тайм-аутам». - это похоже на симптом, а не на настоящую причину. stackoverflow.com/questions/10606720/… Я считаю, что вам нужно изменить строку подключения и установить для MultiSubnetFailover значение «TRUE». techcommunity.microsoft.com/t5/sql-server-support-blog/…
Спасибо за ваш комментарий, но для свойства MultiSubnetFailover уже было установлено значение «True», и оно так не работало.
Где работает SQL Server? РДС?