Обновление .NET Framework, приводящее к тайм-аутам SQL - PullRequest
0 голосов
/ 24 мая 2018

У нас есть приложение, предназначенное для .NET 4.5.1, и оно осталось неизменным.

Однако, когда мы обновили .NET Framework на сервере с 4.5.1 -> 4.7.1, мы началичерез несколько часов после этого произошел тайм-аут SQL (цель приложения осталась на уровне 4.5.1).

"Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached."

Другие серверы, которые имели такую ​​же обработку, также вызвали проблему, поэтому мы искали серьезное изменение в .NET, инашел эту статью: https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/

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

Наше приложение имеет высокий трафик, но мы уверены, что не пропускаем соединения, поскольку это никогда не было проблемой длялет, пока мы не обновили .NET Framework.

Мы собираемся попробовать применить это исправление (и подождать> 24 часа, чтобы увидеть результаты), но есть ли что-то еще, что мы могли бы пропустить?Мы не уверены, что это решение.

РЕДАКТИРОВАТЬ: Даже после отката .NET до 4.5.1 и перезапуска всех серверов, мы все еще видим проблему.Больше ничего не изменилось в кодовой базе, но нам еще предстоит откатить изменение реестра, которое включило SchUseStrongCrypto - если это могло быть причиной?

1 Ответ

0 голосов
/ 02 июня 2018

Я не сталкивался с этим, но ссылка https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/runtime/4.0-4.7.1 указывает на изменение в пуле соединений SQL, где теперь повторные попытки повторяются гораздо дольше.Ссылка также предоставляет параметр для обхода нового поведения;

 ConnectRetryCount = 0

Возможно, что соединения в пуле теперь остаются живыми намного дольше, чем ранее, как побочный эффект или предполагаемая особенность этого изменения поведения,и, следовательно, засорение вашего пула соединений «мертвыми, но повторными соединениями», тогда как раньше они бы умерли?

Это немного умозрительно;но может привести вас на правильный путь.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...