EF Core и большой трафик приводят к ошибке максимального размера пула

Я думаю, что проблема была вызвана сохранением объектов из запросов контекста базы данных в в кеше памяти. У меня был один большой запрос LINQ к контексту базы данных с некоторыми другими подзапросами внутри. Я вызвал FirstOrDefault() в конце основного запроса, но не внутри подзапросов. Контроллер с этим справился, он материализует запросы по умолчанию.

 return this.Context.tRealty.AsNoTracking().Where(
                x => x.Id == id && x.RealtyProcess == RealtyProcess.Visible).Select(
                s => new
                { .....

// subquery
videos = s.TVideo.Where(video => video.RealtyId == id && video.IsPublicOnYouTube).
                        Select(video => video.YouTubeId).ToList()), // missing ToList()
.....
 }).FirstOrDefault();

И была проблема - подзапросы удерживали соединение с контекстом базы данных, когда они сохранялись в в кеше памяти. Когда я реализовал распределенный кеш Redis, сначала он давал сбои из-за каких-то странных ошибок. Это помогает, когда я пишу ToList() или FirstOrDefault() для всех своих подзапросов, потому что распределенному кешу нужны материализованные объекты.

Теперь все мои запросы материализованы в явном виде, и у меня не возникает ошибка максимального размера пула. Так что нужно быть осторожным при сохранении объектов из запросов контекста базы данных в В кэше памяти. Необходимо материализовать все запросы, чтобы не хранить соединение где-то в памяти.

Вы можете установить время жизни DbContext в файле startup.cs, посмотрите, поможет ли это:

    services.AddDbContext<MyDbContext>(options => options
                                       .UseSqlServer(connection), ServiceLifetime.Scoped);

Кроме того, если ваш запрос является простым чтением, вы можете удалить отслеживание, используя .AsNoTracking().

Еще один способ повысить пропускную способность — предотвратить блокировки, используя блок транзакций с IsolationLevel.ReadUncommitted для простых операций чтения. Вы также можете использовать уровень изоляции Snapshot, который является немного более строгим, если вы не хотите грязного чтения.

TransactionOptions transactionOptions = new TransactionOptions() { IsolationLevel = IsolationLevel.ReadUncommitted};
using (TransactionScope transactionScope = new TransactionScope(TransactionScopeOption.Required, transactionOptions))
{
  // insert magic here
}

Изменить. Как упоминал автор вопроса, приведенный выше код невозможен (пока?) в EF Core.

Обходной путь можно найти здесь используя явную транзакцию:

    using (var connection = new SqlConnection(connectionString))
    {
        connection.Open();

        using (var transaction = connection.BeginTransaction())
        {
           // transaction.Commit();
           // transaction.Rollback();
        }
    }

Я не проверял это.

Редактировать 2: еще один непроверенный фрагмент, в котором вы можете выполнять команды для установки уровня изоляции:

                using (var c1= new SqlConnection(connectionString))
                {
                    c1.Open();
                    // set isolation level
                    Exec(c1, "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;");
                    Exec(c1, "BEGIN TRANSACTION;");
                    // do your magic here
                }

С Исполнителем:

        private static void Exec(SqlConnection c, string s)
        {
            using (var m = c.CreateCommand())
            {
                m.CommandText = s;
                m.ExecuteNonQuery();
            }
        }

Изменить 3. Согласно этой теме, транзакции будут поддерживаться, начиная с .NET Core версии 1.2. вперед.

@mukundabrt это отслеживается dotnet/corefx#2949. Обратите внимание, что TransactionScope уже перенесен в .NET Core, но будет доступен только в .NET Core 1.2.

Я добавляю альтернативный ответ на случай, если кто-то попадет сюда с немного другой основной причиной, как это было в случае с моим приложением .NET Core MVC.

В моем сценарии приложение выдавало эти ошибки «время ожидания истекло... достигнут максимальный размер пула» из-за смешанного использования async/await и Task.Result в одном и том же контроллере.

Я сделал это, пытаясь повторно использовать код, вызвав определенный асинхронный метод в моем конструкторе для установки свойства. Поскольку конструкторы не допускают асинхронных вызовов, я был вынужден использовать Task.Result. Однако я использовал async Task<IActionResult> методов для await вызовов базы данных в одном и том же контроллере. Мы обратились в службу поддержки Microsoft, и инженер помог объяснить, почему это происходит:

Похоже, мы делаем блокирующий вызов асинхронного метода внутри [...] конструктора.

...

Итак, в вызове выделенного выше асинхронного метода что-то пошло не так, из-за чего блокируются все перечисленные выше потоки.

Глядя на потоки, которые выполняют ту же операцию и заблокированы:

...

85,71% тем заблокировано (174 темы)

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

https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

https://blogs.msdn.microsoft.com/jpsanders/2017/08/28/asp-net-do-not-use-task-result-in-main-context/

План Действий

Пожалуйста, попросите вашу команду приложения пересмотреть код приложения вышеупомянутого метода, чтобы понять, что происходит не так.

Кроме того, я был бы признателен, если бы вы могли обновить логику своего приложения, чтобы не смешивать асинхронный и блокирующий код. Вы можете использовать await Task вместо Task.Wait или Task.Result.

Итак, в нашем случае я вытащил Task.Result из конструктора и переместил его в приватный async метод, где мы могли await его использовать. Затем, поскольку я хочу, чтобы задача выполнялась только один раз при каждом использовании контроллера, я сохраняю результат в этом локальном свойстве и запускаю задачу из этого метода, только если значение свойства равно null.

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

Надеюсь, это поможет кому-то...