Как исправить утечку памяти при работе с EF?

Question

[artshelom]

Запустил сервис, который работает по циклу. Но появилась проблема, что кол-во потребляемой памяти только растет.

while (!stoppingToken.IsCancellationRequested)
{
    var countPayments = db.Payments.Where(a => a.TypePayment == Data.Payments.TypePayment.Activity).Count();
    foreach (var payment in checkPayments)
    {
        var payment = db.Payments.Where(a => a.TypePayment == Data.Payments.TypePayment.Activity).OrderBy(a => a.Id).Skip(i)
            .Take(1).Include(a => a.Subscription).Include(a => a.Promocodes).FirstOrDefault();
        var telegramUser = db.TelegramUsers.Where(a => a.Id == payment.TelegramUserId).FirstOrDefault();

        if (payment == null || telegramUser == null)
            continue;

        try
        {
            CheckBlaBla(payment, telegramUser );
        }
        catch (Exception e)
        {
            throw e;
        }
        payment = null;
        telegramUser = null;
        GC.Collect();
        GC.WaitForPendingFinalizers();
    }
}

Обычный сервис BackgroundService.
Если принудительно очищаю как ниже все становится вроде хорошо. Но немного не понимаю. Почему после потери ссылки, не удаляются из памяти (как в дебаге, так и в релизе). Какие ограничения можно поставить в конфиге? или только так с этим бороться?

payment = null;
telegramUser = null;
GC.Collect();
GC.WaitForPendingFinalizers();

Comments

[Василий Банников]

payment = null;
        telegramUser = null;
        GC.Collect();
        GC.WaitForPendingFinalizers();

Вот так писать не следует.
Лучше возьми dotmemory и посмотри, на что память уходит

[artshelom]

Василий Банников, На хранение этих объектов в памяти. Уже посмотрел

[Василий Банников]

artshelom, и сколько уходит? Может у вас просто gc не успел включиться, с вы уже паникуете?
ServerGC используете?

[Василий Банников]

artshelom, добавь вот это в csproj, если ещё нет.

<PropertyGroup>
<ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>

[artshelom]

Василий Банников, До 550мб. А дальше ждать надоело выключил.
В настройках проекта прописал:

<ServerGarbageCollection>true</ServerGarbageCollection>

И не видел, чтобы кол-во памяти уменьщалось

[Василий Банников]

artshelom, 550мб - это ещё ок.
Сколько памяти на машине?

[Василий Банников]

artshelom, о. Пропиши ещё AsNoTracking, когда вытаскиваешь из БД.
Вероятно change tracker держит ещё ссылку, и не даёт собрать мусор

[artshelom]

Василий Банников, На сервере где публикую в начале было 500мб. И сервер писал о выключении моего проекта. После увеличил до 1гб и после сделал этот код по очистке. И все норм стало.

[Василий Банников]

artshelom, ну вот я бы попробовал change tracker отрубить, и вытаскивать данные не по одному объекту, а сразу пачками, чтобы GC было легче

[artshelom]

Василий Банников Сделал как вы сказали. Но память все равно уходит. Но намного меньше доходит до 250 мб, а потом расстет намного меньше

[Василий Банников]

artshelom, 250мб это уже совсем ок.
В Release же собираете?

[Василий Банников]

artshelom, ещё можно синхронный Count, First, ToList и тд заменить на асинхронные.

[AndromedaStar]

artshelom,

foreach (var payment in checkPayments)
    {
        var payment = db.Payments.Where(a => a.TypePayment == Data.Payments.TypePayment.Activity).OrderBy(a => a.Id).Skip(i)
            .Take(1).Include(a => a.Subscription).Include(a => a.Promocodes).FirstOrDefault();

Вас не смущает, что происходит тут с переменной payment?
Плюс не стоит вызывать GC.Collect() в цикле. Совсем не стоит.
Вообще, если вы пишете в обычном режиме, то нужно забыть о существовании такой возможности, в C# автоматическая сборка памяти. Ее принудительная сборка на 99 процентов только вредит, особенно если пользоваться бездумно.

Answer 1

[Василий Банников]

1. Кучу памяти сжирает change tracker в EF, так что первым шагом его отключаем, добавляя AsNoTracking к каждому запросу.
А там где действительно нужно отcлеживать изменения - отсоединяем объекты, когда они не нужны при помощи Detach
2. Включаем ServerGarbageCollection, чтобы сборщик мусора мог работать в несколько потоков
3. Заменяем синхронные вызовы EF на асинхронные.
По идее тоже должно немного помочь
4. Вытаскиваем объекты из базы не по одному, а пачками штук по 100, тк GC проще работать с большими кусками, чем с маленькими
5. Если я правильно понимаю, это у вас HostedService.
В таком, случае смотрите внимательно на использование контекста, тк ещё в другом месте может Change Tracker нагружаться

Comments

[artshelom]

А можете ещё подсказать почему плох?
GC.Collect();
GC.WaitForPendingFinalizers();

[artshelom]

@vadka
Спасибо. Попробую. Я же правильно понимаю, что сборщик муссора работает только с определенного момента, то есть когда критическая масса набирается. А не по таймингу, или он умный и сам как-то понимает?

[Василий Банников]

artshelom, По тому что это триггерит сборку ВСЕГО мусора, а не тех пары объектов, что у вас выделилось за итерацию цикла.
А раз собирает оно мусор со всего приложения - тогда и тормозить будет всё приложение целиком - это раз.

Два - оно даже в finally не завёрнуто, а по тому сборка будет не всегда принуждаться.

Лучше смотри, что можно поднастроить: https://docs.microsoft.com/en-us/dotnet/core/run-t...

[Василий Банников]

artshelom, там вроде как-то по поколениям GC будет по-разному работать.
Долгоживущие объекты собираются только тогда, когда уже к OOM близок.
В соседнем ответе есть ссылка с описанием.

Answer 2

[Акылбек Омар]

Документацию можно прочитать здесь: Ссылка