ПРОБЛЕМА:
Начиная с миграции БД, у меня много случайных исключений из таймаута SQL.Все, что я сейчас после 2 месяцев исследования:
- Все мои приложения .NET C #, использующие EF 6, подвергаются воздействию
- В любое время дня (дня или ночи), НО тем большетрафика, который мы имеем, тем больше тайм-аутов
- Независимо от того, какой метод используется (.ToList, .Single, .First, .SaveChanges), который инициирует вызов к БД
- Независимо от того, на какую таблицу БД это повлияломаленький или большой)
- Какой бы ни была сложность запроса (большой запрос с 20 соединениями или простой или маленький запрос с выбором ... где Id = 1)
- Независимо от режима вызова (запись / чтение)
- Независимо от вызова dbContext напрямую или с помощью навигации по свойствам (с активированной отложенной загрузкой)
ОКРУЖАЮЩАЯ СРЕДА:
> ИНФРАСТРУКТУРА:
- 1 AWS RDS (db.m4.2xlarge), 32 ГБ ОЗУ, 8 ВЦП, 100 ГБ SSD с SQL SERVER 11.0.xxx с уровнем изоляции Read Committed Snapshot
- UC около 5%, DB соединения около 45, очень мало E / S записи или чтения, 20 ГБ ОЗУ доступно (на 32 ГБ), 90ГБ свободного места (на 100 ГБ SSD)
- Оптимизация индекса (перестроить, удалить / создать), план запроса, статистика
- Увеличение параллелизма
- НЕТ блокировок, НЕТ тупиков, НЕТприостановленный сеанс (sp_who2), нет проблемы CXPACKET, очень большой объем свободной памяти или дискового пространства
- Использование BD: около 25 запросов в секунду, ничего исключительного ...
>ПРИЛОЖЕНИЯ:
- 20 приложений C # (Batch, UI ASP MVC, ...) в основном с EF 6 (активирована отложенная загрузка) или EF Core с CommandTimeout до 45 с (вместо 30 с по умолчанию)
- Оптимизация LINQ to Entities (Inlcude, заменяется на raw sql для очень сложного запроса, удаление WHERE 1 = 0 запросов, ...)
- Оптимизировано управление DbContext (открывать / закрывать по необходимости,нет утечки соединения)
- Добавлено много кэшей памяти, чтобы избежать вызова БД
- Все пулы приложений перезагружаются каждый день
ИСКЛЮЧЕНИЕ:
Когда.ToList, .First, .Single или любой метод, который инициирует вызов tБД из EF выдает следующее сообщение:
System.ComponentModel.Win32Exception: The wait operation timed out.
или
System.Data.SqlClient.SqlException A transport-level error has occurred when receiving results from the server. (provider: Session Provider, error: 19 - Physical connection is not usable)
РЕЗУЛЬТАТ:
Когда я запускаю SQL Profiler в моей базе данных PROD (невозможно воспроизвестипроблема в среде других разработчиков), у меня есть запрос, который выполняется только 1 сек (не 45 сек ...), и мой код возвращает только через 45 секунд тайм-аут ... Как проблема была на сетевом / транспортном уровне ... Нокак это контролировать?Как быть уверенным, что проблема была не в C # или сервере БД, а между 2?У вас есть какой-нибудь совет, чтобы эти тайм-ауты исчезли до того, как я убил себя?
РЕДАКТИРОВАТЬ 22/04/2019:
Я подтверждаю, что когда EF 6 выполняет запрос (например, запускается с помощью .ToList), запрос к моей базе данных занял всего 78 микросекунд (да, микросекунд ...) для выполнения и ... EF ждут 45 секунд, чтобы выдать мне ошибку типа "Произошла ошибка транспортного уровня ...":ЗАЧЕМ ?Почему EF 6 не получает результат из базы данных?Почему ответ теряется в дикой природе?Как соединение, потерянное случайно ...
РЕДАКТИРОВАТЬ 25/04/2019:
Наконец мы решили разработать стратегию DbExecutionStrategy с системой повторных попыток.Мне очень грустно кончать так, но у нас не хватает времени, и это решило наши проблемы.