EF Core PostgreSQL использует много памяти и не очищает ресурсы

@HF · Регистрация: 09.09.2011

Author24 — интернет-сервис помощи студентам

Столкнулся с проблемой и не могу понять уже куда ещё посмотреть и что проверить.
Приложение состоящее из проектов NetCore и один WebApp с Angular. Работа с БД: EF Core + EF Core postgresql.
Ситуация: запускаем проект, активируем экшен, который запускает метод, который работает с несколькими таблицами. Несколько таблиц только читаем, анализируем, одна в которой обновляем одно поле (то что нашли после анализа), в одну просто добавляем итоговые данные.
Смотрим память. Запуск проекта: 80мб. После окончания всех действий, до SaveChanges - 1.5Гб. После записи делаем context.Dispose() (+ GC.Collect() ). Память возвращается в 144 мб. Делаем снова запуск. Пик - 2+Гб, после очистки - 200+. Вообщем имеем накопительный эффект 50-100Мб.

Самое интересное, суть вопроса и не понимания.
Открываем все csproj файлы, меняем TargetFramework с netcoreapp2.1 на net462.
Смотрим память. Запуск проекта: 44мб. После окончания всех действий, до SaveChanges - 1.5Гб. После записи делаем context.Dispose() (+ GC.Collect() ). Память возвращается в 44 мб.

Что я нашёл. Делал снапшоты в дебаггере и обнаружил вся память копится в npgsql.changetracker.(что-то-там). Не знаю за обычный EF, может быть это одинаковая проблема. Получается что или npgsql не делает dispose или существуют какие-то не убиваемые связи, которые невозможно очистить.
НО! Почему при таргет=net462 таких проблем нет? Один и тот же код, разный эффект. Что на это влияет? Какие есть ньюансы? Уже весь интернет перекопал. Делал в конфиге настройку ServerGarbageCollection. Помогло, но не на много (- 50Мб).
Ну и пока из того что видно - с таргетингом на коре, памяти всё равно на всё тратится больше. Даже просто запущенный проект "весит" раза в 2 больше.

Тоже что я сказал, но на другом языке и другими словами
Kestrel on ASP.NET Core - high memory usage with netcore1.1 compared to targeting net 4.6

И просто "хот" тема на официальном гитхабе с тоже похожим симптомом.
https://github.com/aspnet/Home/issues/1976

@Usaga · 04.09.2018, 19:58

Сообщение от HF

вся память копится в npgsql.changetracker.(что-то-там).

Ага. Типичная тема. AsNoTracking() надо использовать и не пытаться выгружать всю базу в оперативку.

@HF · 04.09.2018, 21:00 **[ТС]**

Сообщение от Usaga

Ага. Типичная тема. AsNoTracking() надо использовать и не пытаться выгружать всю базу в оперативку.

А если нужен трекинг, потому что в задании обновляются свойства у разных объектов и потом всё оптом сливается?

И главное. Я попытался это описать, но меня наверное это больше всего и интересует. Почему мы меняем ТаргетФреймворк с NetCore на Net и... всё работает по другому. Ресурсы почти идеально и самостоятельно вычищаются.

То что после обновления Core с 2.0 на 2.1 занятая память увеличилась очень значительно, я вообще молчу. Пока что у меня на счёт NetCore только негативные впечатления. Что про настройку, что про ресурсы.

@Usaga · 05.09.2018, 05:12

Сообщение от HF

А если нужен трекинг, потому что в задании обновляются свойства у разных объектов и потом всё оптом сливается?

Обновляете свойства, а потом добавляете объект в контекст (Attach). Имеет смысл, когда только некоторые объекты из выгруженных обновляются.

Сообщение от HF

Почему мы меняем ТаргетФреймворк с NetCore на Net и... всё работает по другому. Ресурсы почти идеально и самостоятельно вычищаются.

Сборщик мусора работает иначе. Вполне возможно, что в Core (предположение) сборщик допускает размер нулевого и первого поколений сильно большего размера (для целей производительности).

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

Было бы здорово увидеть фрагмент кода порождающий такое количество мусора. Я думаю, что его можно будет переделать по-нормальному.

@HF · 12.09.2018, 01:02 **[ТС]**

Несколько ночей, эксперименты, поиски решений и причин. Проблема найдена. Дело не в репозиториях.
Напомню что проблема прозошла при переходе с net462 на netcoreappX.X

При создании огромного количества записей в таблице, всё это "добро" оседает в памяти и никак не хочет больше удаляться.
То есть если мы очень много объектов добавляем через context.table.Add(object) и потом через какое-то время решим сделать SaveChanges(), то всё что "накоплено тяжким трудом, две куртки..." остаётся в памяти и не помогает никакой Dispose и насильственные очистки объектов и выполнения сборщика мусора.
Сложность и объёмы усугубляются связанными объектами, которые автоматически создаются вместе (например User имеет внутри ссылку на UserInfo который тоже автоматом создастся).

Решений много и все они плохие.

- после каждого Add делаем SaveChanges. Получаем обильные потери в скорости. Но идеальную очистку памяти (никаких прибавок не происходит).
- делаем запись через AddRange. Получаем тот же самый Add только немного быстрее. И никакой очистки ресурсов (ну может быть какой-то минимальный %)
- и единственный рабочий способ - библиотеки типа Z EF Extension с bulk-методами. Огромная скорость, почти никакой утечки.

Выводы. При переходе с .Net на .NetCore получаем в 2-3 раза больше занятой памяти и другой механизм очистки памяти. Если раньше ресурсы очищались быстрее и лучше, то сейчас в наличии большие приросты занятой памяти и долгое их хранение со сложностями в удалении.
Чем больше версия NetCore, тем ещё больше памяти приложение начинает занимать даже при начальном старте. И это всё заметные приросты.
Большая печаль этот Коре. Интересно что будет в скором 3.0.

@Usaga · 12.09.2018, 04:37

HF, вы не показали код сохранения записей, где якобы происходят "утечки". Поэтому я остаюсь при мнении, что утечки в вашем коде, а не в Core. И были они до перехода приложения с .NET Framework на .NET Core. Просто сменилась логика работы сборщика мусора и всё тайное стало явным.

@HF · 13.09.2018, 21:47 **[ТС]**

Сообщение от Usaga

Просто сменилась логика работы сборщика мусора и всё тайное стало явным.

Сообщение от Usaga

Сборщик мусора работает иначе. Вполне возможно, что в Core (предположение) сборщик допускает размер нулевого и первого поколений сильно большего размера (для целей производительности).

Это предположение нигде не описано. Я прочитал все возможные статьи связанные с изменениями в версиях, по темам сборщика мусора, работы кэша и т.п. Если у них добавился функционал, то должны быть и настройки. Все настройки связанные с памятью я проверил. Это опция отключения серверного кэша и все возможные трекинги и автодетекторы изменений.
Так или иначе "сборщик мусора работает иначе". Это даже видно по диагностики. Если .Net собирает сразу после закрытия зоны видимости (форич, юзинг и т.п.), то кор делает это слишком редко. Это даже больше похоже на временной автосборщик (4 раза за 10 секунд, повторения на всём протяжении), а не на явную причину сборки.

Сообщение от Usaga

Было бы здорово увидеть фрагмент кода порождающий такое количество мусора. Я думаю, что его можно будет переделать по-нормальному.

Код специфический и нет смысла его сюда выкладывать. А если убрать лишнее, то я только замучаюсь вырезать, да и смысл может быть утерян.
Я сделал иначе - создал просто 3 проекта - ConsoleApp. Просто Net462 + ef6, 2) net462 + ef core, 3 - netcore + efcore. Создаём одну простую модель Id, Name. И просто циклом добавляем 100_000 объектов. Потом делаем SaveChanges. И ужасаемся.
Прим. речь о постгресе уже не идёт. Это даже без него воспроизводится. Я думал проблема в нём.
Если в старой версии я даже не видел увеличения памяти, то в Коре она растёт линейно. Если в нормальной ситуации, любой Dispose даёт выгрузку памяти, то в Core вообще ничего не меняется. Если при удалении объекта и вызове GC есть результат, то в Core мало что меняется.
Я бы не стал спорить, если бы это не был Одинаковый код, одинаковый подход. Но в одной версии он всегда давал нормальный результат, а в Коре совершенно другой. Если вы считаете что это вылезли баги, то... ну проверьте тот пример что я сказал. Банально 100_000 объектов, чтобы увидеть заполнение.

Я прошуршал даже официальный репозиторий EF. После выхода 2.0 количество жалоб на огромное использование памяти стало частым вопросом. В единичных случаях действительно вроде бы помогают (народ уходит говоря спасибо), но в большинстве это обычные баги с огромными картинками доказательств. Несколько таких сообщений отметили как баг и (я так понял) поставили в работу в версии 3.0.

Быстрый пример одного Issue
https://github.com/aspnet/Enti... sues/13048
моя ситуация примерно такая же. Один контекст, разные репозитории, смена репозиториев, какие-то действия в них.

@Usaga · 14.09.2018, 06:34

Сообщение от HF

Так или иначе "сборщик мусора работает иначе". Это даже видно по диагностики. Если .Net собирает сразу после закрытия зоны видимости (форич, юзинг и т.п.), то кор делает это слишком редко. Это даже больше похоже на временной автосборщик (4 раза за 10 секунд, повторения на всём протяжении), а не на явную причину сборки.

Это и есть "работает иначе". Сборка мусора начинается, когда забивается нулевое поколение. Привязок к "форич" и "юзинг" нет. Если в Core размер кучи под нулевое поколение больше, чем в .NET (в котором можно в app.config выбрать из нескольких сборщиков мусора), то забиваться куча будет дольше, соответственно, и сборки будут реже.

Так же, Core более эффективно написан (под капотом), там сделали большую работу по уменьшению аллокаций памяти. Это тоже может влиять на скорость забивания кучи.

Сообщение от HF

Быстрый пример одного Issue

Исходя из прочитанного, могу сделать вывод, что EF Core - кусок г***а несмотря на версию 2.1. Посмотрите в сторону Linq To Db. Да, это не такой комбайн как EF \ EF Core, но таких подстав он не делает.

@HF · 14.09.2018, 08:42 **[ТС]**

Сообщение от Usaga

Исходя из прочитанного, могу сделать вывод, что EF Core - кусок г***а несмотря на версию 2.1. Посмотрите в сторону Linq To Db. Да, это не такой комбайн как EF \ EF Core, но таких подстав он не делает.

Мне нравится технологическое развитие, я всегда за "движуху". Но в данном случае пока не вижу, чтобы преимущества Core перевешивали так, что я бы сразу без раздумий переходил на него с обычного .Net. Да, он быстрее в разы, да, он мультиплатформен. И на этом всё заканчивается, потому что все те плюсы которые он даёт - за счёт обильных ресурсов, плюс многое не сразу понятно и не так очевидно, а некоторые вещи там работают по умолчанию, хотя нам они не нужны (пример, если я правильно понял, то в EF Core DI там теперь обязательный и всегда там что-то выполняет).
Эксперименты я ещё продолжу, может быть и найду решение. Пока ничего не понятно.

Сообщение от Usaga

Исходя из прочитанного, могу сделать вывод, что EF Core - кусок г***а несмотря на версию 2.1. Посмотрите в сторону Linq To Db. Да, это не такой комбайн как EF \ EF Core, но таких подстав он не делает.

Проект развёрнут по задаче на Core/EF Core. Переделывать всю архитектуру нельзя.

@Usaga · 14.09.2018, 08:58

HF, дело не в .NET Core, а именно в EF Core. Судя по описанию подтверждённой проблемы, EF Core кеширует контексты, через репозитории\хелперы, методы которых используются в запросах. Т.е. кешируются именно запросы, но с ними сохраняется и ссылка на объект, чей метод вызывался в запросе (в примере по ссылке: Select()). Если в объекте есть ссылка на контекст, то получаем то, что получаем.

Поэтому GC и не может снести задиспоженный контекст, ибо на него есть ссылка в кеше EF-а. Решение: не вызывать методы экземпляров в запросах EF-а. В принципе, не такое уж и трудное и глобальное изменение.

Добавлено через 2 минуты
У вас такой сценарий? После диспоза и явного вызова GC.Collect() объект контекста остаётся в куче?

@HF · 14.09.2018, 14:07 **[ТС]**

Сообщение от Usaga

У вас такой сценарий? После диспоза и явного вызова GC.Collect() объект контекста остаётся в куче?

Да, так. Но это не сценарий. Мы стали искать причину и решения. Соотственно стали смотреть, что изменится, если удалять объект (.Dispose() или = null). Наоборот с этим подходом больше стало вычищаться, чем если вообще ничего не делать.

Сообщение от Usaga

Поэтому GC и не может снести задиспоженный контекст, ибо на него есть ссылка в кеше EF-а. Решение: не вызывать методы экземпляров в запросах EF-а. В принципе, не такое уж и трудное и глобальное изменение.

Не уверен что понял правильно, уточните пожалуйста примером о чём речь - "методы экземпляров в запросах EF-а".

@Usaga · 14.09.2018, 14:15

HF, по ссылке на тикет на гитхабе, что вы привели, сценарий утечки памяти чётко расписан: если в IQueryable есть обращение к какому-то классу, то ссылка на этот класс сохраняется где-то в недрах кеша EF-а.

Note for triage: I was able to reproduce this. The key part is that the query includes a call to an opaque instance method on the the repository:

C#

public IQueryable<int> GetInt()
{
    return _context.TestEntities.Select(t => HashCode(t.DateRange1));
}
 
private int HashCode(string dateRange1)
{
    return dateRange1.GetHashCode();
}

Note that the repository holds a reference to the context. Removing the opaque call makes the leak go away:

C#

public IQueryable<int> GetInt()
{
    return _context.TestEntities.Select(t => t.DateRange1.Length);
}

Репозиторий, который держит ссылку на контекст, пихает в Select свой приватный метод. Всё выражение кешируется в EF-е и ссылка на репозиторий тоже. Когда приходит время убирать мусор, GC не может удалить контекст с его раздутым кешем, ибо на него есть ссылка из репозитория, ссылка на который зависла где-то в кеше EF-а.

Вот вам и утечка.

Там же рекомендовали не обращаться к методам экземпляров классов (любых) из передаваемых в LINQ-расширения лямбд. Или использовать статические методы.

@HF · 16.09.2018, 17:40 **[ТС]**

Если кому-то это будет интересно и полезно, то вот мой рассказ.

"Тысяча" тестов показала, что новый Core + Core EF создают нехорошую ситуацию с использованием памяти.

Причина поисков: при создании объектов и последующей записи через AddRange, SaveChanges начинает линейно заполнять память и после окончания выполнения память не восстанавливается. Подозрения что Dispose не выполняется, соответственно оставляя всё в памяти.

Тестовый солюшен:
- проект - модель данных, проекты ConsoleApp, ConsoleCoreApp, WebCoreApp
- модель, состоит из User, Permission. User имеет связь с Permission. Модели "бедные", без какой-либо реализации.
- dbContext - EF + mssql (localdb)
- производится запись созданных 100_000 User с заполненным Permission
- цикл производится 3 раза, для сравнения и ожидания очистки памяти
- анализ памяти через снапшоты VS Diagnostic

Итоговые результаты:
- EF Core затягивает за собой хвалёный Microsoft.Extension.DependencyInjection и везде его использует. То есть даже если у нас в проекте не будет использован DI, то он всё равно есть, как суслик. При анализе памяти он обнаруживается везде где только можно. В том числе как какая-то связь с моделью данных.
- Как оказалось, на самом деле DI выполняет обещанный Dispose везде, где должен, как и обещалось в документации Microsoft. Это конечно большое удобство и плюс в его честь.
- но минус в том, что в памяти создаётся просто огромное (на мой взгляд) количество объектов, которые возможно управляют состоянием модели и т.п. операций EF. Например для 3000 добавленных объектов появилось кроме этих объектов ещё 5 раз по 3000 каких то других объектов, связанных с моделью. В случае с 100000 объектами это соотственно память * 5.
- если проект не Web, то управлять выгрузкой памяти нужно обязательно, т.к. автоматическим Dispose занимается DI, а выгружается он только когда приложение закроется.
Главное:
- память почти никогда не выгружается на начальное состояние
- но отладчик показал, что на самом деле объектов вычищаются!
т.е. делаем несколько снапшотов и видим что при окончании всего жизненного цикла приложения, все диспозы выполнились и количество объектов в снапшоте равно количеству добавленных. Но при этом оперативная память остаётся на заполненном уровне.
- при выполнении проектов в Release режиме, память вообще ведёт себя неадекватно и я даже не понял зависимости

Ещё осталось провести тесты с полным забиванием памяти, в надежде что он сам начнёт чистить её при необходимости. Но...сомнительно.

Итог:
- EF Core и DependencyInjection страшное зло
-- EF Core использует очень много памяти. Наверное это кэширование и какие-нибудь эффективные правила, но за на счёт. В сравнении с EF6 ровно в два раза.
+ EF Core для AddRange использует MERGE - но не с большим количеством записей. Но тоже большой плюс, не нужно использовать сторонние BULK библиотеки.
- всегда желательно управлять внутренними ресурсами. Использовался список - нужно его явно зачистить и удалить. Больше шансов что быстрее выгрузится.

@Usaga · 16.09.2018, 17:58

HF, самое прикольное, что люди жалуются и на наличие "классической" болячки EF-а - разогрев. В EF6.X он был конским. В EF Core он стал лучше, но и функционала в нём меньше. И на то, что люди жалуются на разогрев больших контекстов длящийся МИНУТАМИ, разрабы отвечают так:

@Usaga · 16.09.2018, 18:00

Т.е. на жалобы о том, что продукт является неюзабельным на практике дерьмом, авторы отвечают: "у нас есть более приоритетные задачи". Для кого оно пишется - не понятно.

Если есть возможность, то используйте что-нибудь другое. Да, не так удобно, но и подстав будет меньше.

@HF · 16.09.2018, 19:05 **[ТС]**

Сообщение от Usaga

Если есть возможность, то используйте что-нибудь другое. Да, не так удобно, но и подстав будет меньше.

У нас проект на Core 2.0 + EF Core 2.0. Мы просто решили что пора наверное обновиться в пользу улучшения так сказать. И начали тесты проводить. И первые же наблюдения выявили такие странности. Решил от любопытства выяснить - это у нас неправильно что-то, или обновление не такое уж и решение.

Сообщение от Usaga

самое прикольное, что люди жалуются и на наличие "классической" болячки EF-а - разогрев. В EF6.X он был конским. В EF Core он стал лучше, но и функционала в нём меньше. И на то, что люди жалуются на разогрев больших контекстов длящийся МИНУТАМИ

Сообщение от Usaga

Т.е. на жалобы о том, что продукт является неюзабельным на практике дерьмом, авторы отвечают: "у нас есть более приоритетные задачи". Для кого оно пишется - не понятно.

Это подтверждает моё мнение (где-то темка была с обсуждением), что Core пока продукт абсолютно не юзабельный, так как находится на стадии активного развития. И каждая версия может кардинально отличаться друг от друга. Плюс к этому, если раньше считалось что Core это улучшение обычного Net, то сейчас уже чётко видно, что это совсем другой продукт со своими багами и глюками, которых в простом Net - нет.
Скоро 3.0. Может быть все усилия бросили в эту ветку? Но если старые проблемы перенесут туда, то это будет жуткая жопа.

Ещё уточню, что я проводил тесты с проектами ConsoleApp + Core. Там такая же ситуация с памятью, но там хотя бы Dispose и GC.Collect явно отрабатывают и вычищают всё.

Можно тему перенести в форум "C#: Базы данных, ADO.NET". Там ему больше места, чем тут. Изначально я считал что проблема в самом Core или AspCore.

@Usaga · 17.09.2018, 03:42

.NET Core и ASP.NET Core - зрелые продукты. А вот EF Core выглядит, что разрабатывается "на сдачу", чисто чтобы было. Косяки "классического" EF были известны уже давно, и это не производительность (она была приемлемой). Но в EF Core приоритет отдаётся чему попало.

Попробуйте EF Core 2.2, который недавно вышел в Preview 2. Может там получше стало с памятью. Версия 2.2 у них идёт как корректирующая, без новых фич, чисто исправление багов.

А вообще, ребята работающие над EF Core сказали недавно, что ведут работу по портированию EF 6 (будущая версия EF 6.3) на .NET Core 3.0. Объясняется тем, что так людям будет легче потихоньку мигрировать на Core, что больше звучит как признание того, что EF Core у них не получается нормальным продуктом.

@HF · 17.09.2018, 14:33 **[ТС]**

Сообщение от Usaga

А вообще, ребята работающие над EF Core сказали недавно, что ведут работу по портированию EF 6 (будущая версия EF 6.3) на .NET Core 3.0. Объясняется тем, что так людям будет легче потихоньку мигрировать на Core, что больше звучит как признание того, что EF Core у них не получается нормальным продуктом.

Не хотел тему вопроса в тему обсуждения превращать, но чем более читаю и разбираюсь, тем больше отвращение. Вот что ещё пишут в комментариях.

I’m looking forward to 3.0 with regard to improvements in the LINQ provider, or any improvements to the LINQ provider in general. That is one of the most important parts of EF IMHO. I am still stuck using EF 6 for some of my queries. It would be nice if one day EF Core could handle all the queries that EF 6 does without kicking off an unacceptable number of N+1 queries. Some of the EF 6 queries looked horrific in terms of tons of joins, but, actually worked acceptably.

Будем ждать и надеяться 3.0. Вроде бы уже скоро.

@Usaga · 17.09.2018, 14:39

HF, первый квартал 2019-го кода. Это не так уж и скоро. За это время много чего уже можно написать.

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
		1
	EF Core PostgreSQL использует много памяти и не очищает ресурсы 31.08.2018, 20:23. Показов 4310. Ответов 18 Метки memoryleak, netcore, entity framework (Все метки) Столкнулся с проблемой и не могу понять уже куда ещё посмотреть и что проверить. Приложение состоящее из проектов NetCore и один WebApp с Angular. Работа с БД: EF Core + EF Core postgresql. Ситуация: запускаем проект, активируем экшен, который запускает метод, который работает с несколькими таблицами. Несколько таблиц только читаем, анализируем, одна в которой обновляем одно поле (то что нашли после анализа), в одну просто добавляем итоговые данные. Смотрим память. Запуск проекта: 80мб. После окончания всех действий, до SaveChanges - 1.5Гб. После записи делаем context.Dispose() (+ GC.Collect() ). Память возвращается в 144 мб. Делаем снова запуск. Пик - 2+Гб, после очистки - 200+. Вообщем имеем накопительный эффект 50-100Мб. Самое интересное, суть вопроса и не понимания. Открываем все csproj файлы, меняем TargetFramework с netcoreapp2.1 на net462. Смотрим память. Запуск проекта: 44мб. После окончания всех действий, до SaveChanges - 1.5Гб. После записи делаем context.Dispose() (+ GC.Collect() ). Память возвращается в 44 мб. Что я нашёл. Делал снапшоты в дебаггере и обнаружил вся память копится в npgsql.changetracker.(что-то-там). Не знаю за обычный EF, может быть это одинаковая проблема. Получается что или npgsql не делает dispose или существуют какие-то не убиваемые связи, которые невозможно очистить. НО! Почему при таргет=net462 таких проблем нет? Один и тот же код, разный эффект. Что на это влияет? Какие есть ньюансы? Уже весь интернет перекопал. Делал в конфиге настройку ServerGarbageCollection. Помогло, но не на много (- 50Мб). Ну и пока из того что видно - с таргетингом на коре, памяти всё равно на всё тратится больше. Даже просто запущенный проект "весит" раза в 2 больше. Тоже что я сказал, но на другом языке и другими словами Kestrel on ASP.NET Core - high memory usage with netcore1.1 compared to targeting net 4.6 И просто "хот" тема на официальном гитхабе с тоже похожим симптомом. https://github.com/aspnet/Home/issues/1976 1

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	04.09.2018, 19:58	2
	Сообщение от HF вся память копится в npgsql.changetracker.(что-то-там). Ага. Типичная тема. `AsNoTracking()` надо использовать и не пытаться выгружать всю базу в оперативку. 0

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
	04.09.2018, 21:00 [ТС]	3
	Сообщение от Usaga Ага. Типичная тема. AsNoTracking() надо использовать и не пытаться выгружать всю базу в оперативку. А если нужен трекинг, потому что в задании обновляются свойства у разных объектов и потом всё оптом сливается? И главное. Я попытался это описать, но меня наверное это больше всего и интересует. Почему мы меняем ТаргетФреймворк с NetCore на Net и... всё работает по другому. Ресурсы почти идеально и самостоятельно вычищаются. То что после обновления Core с 2.0 на 2.1 занятая память увеличилась очень значительно, я вообще молчу. Пока что у меня на счёт NetCore только негативные впечатления. Что про настройку, что про ресурсы. 0

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	05.09.2018, 05:12	4
	Сообщение от HF А если нужен трекинг, потому что в задании обновляются свойства у разных объектов и потом всё оптом сливается? Обновляете свойства, а потом добавляете объект в контекст (Attach). Имеет смысл, когда только некоторые объекты из выгруженных обновляются. Сообщение от HF Почему мы меняем ТаргетФреймворк с NetCore на Net и... всё работает по другому. Ресурсы почти идеально и самостоятельно вычищаются. Сборщик мусора работает иначе. Вполне возможно, что в Core (предположение) сборщик допускает размер нулевого и первого поколений сильно большего размера (для целей производительности). Но надо понимать, что полтора гигабайта не с неба упали, это - ваши данные. И если такие объёмы расходуются при одном запросе, то это значит, что вы выгружаете в память всю базу. Т.е. я считаю, что тут не баг .NET Core или провайдера постгреса, а у вас в коде какая-то дичь. Было бы здорово увидеть фрагмент кода порождающий такое количество мусора. Я думаю, что его можно будет переделать по-нормальному. 1

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
	12.09.2018, 01:02 [ТС]	5
	Несколько ночей, эксперименты, поиски решений и причин. Проблема найдена. Дело не в репозиториях. Напомню что проблема прозошла при переходе с net462 на netcoreappX.X При создании огромного количества записей в таблице, всё это "добро" оседает в памяти и никак не хочет больше удаляться. То есть если мы очень много объектов добавляем через context.table.Add(object) и потом через какое-то время решим сделать SaveChanges(), то всё что "накоплено тяжким трудом, две куртки..." остаётся в памяти и не помогает никакой Dispose и насильственные очистки объектов и выполнения сборщика мусора. Сложность и объёмы усугубляются связанными объектами, которые автоматически создаются вместе (например User имеет внутри ссылку на UserInfo который тоже автоматом создастся). Решений много и все они плохие. - после каждого Add делаем SaveChanges. Получаем обильные потери в скорости. Но идеальную очистку памяти (никаких прибавок не происходит). - делаем запись через AddRange. Получаем тот же самый Add только немного быстрее. И никакой очистки ресурсов (ну может быть какой-то минимальный %) - и единственный рабочий способ - библиотеки типа Z EF Extension с bulk-методами. Огромная скорость, почти никакой утечки. Выводы. При переходе с .Net на .NetCore получаем в 2-3 раза больше занятой памяти и другой механизм очистки памяти. Если раньше ресурсы очищались быстрее и лучше, то сейчас в наличии большие приросты занятой памяти и долгое их хранение со сложностями в удалении. Чем больше версия NetCore, тем ещё больше памяти приложение начинает занимать даже при начальном старте. И это всё заметные приросты. Большая печаль этот Коре. Интересно что будет в скором 3.0. 0

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	12.09.2018, 04:37	6
	HF, вы не показали код сохранения записей, где якобы происходят "утечки". Поэтому я остаюсь при мнении, что утечки в вашем коде, а не в Core. И были они до перехода приложения с .NET Framework на .NET Core. Просто сменилась логика работы сборщика мусора и всё тайное стало явным. 0

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
	13.09.2018, 21:47 [ТС]	7
	Сообщение от Usaga Просто сменилась логика работы сборщика мусора и всё тайное стало явным. Сообщение от Usaga Сборщик мусора работает иначе. Вполне возможно, что в Core (предположение) сборщик допускает размер нулевого и первого поколений сильно большего размера (для целей производительности). Это предположение нигде не описано. Я прочитал все возможные статьи связанные с изменениями в версиях, по темам сборщика мусора, работы кэша и т.п. Если у них добавился функционал, то должны быть и настройки. Все настройки связанные с памятью я проверил. Это опция отключения серверного кэша и все возможные трекинги и автодетекторы изменений. Так или иначе "сборщик мусора работает иначе". Это даже видно по диагностики. Если .Net собирает сразу после закрытия зоны видимости (форич, юзинг и т.п.), то кор делает это слишком редко. Это даже больше похоже на временной автосборщик (4 раза за 10 секунд, повторения на всём протяжении), а не на явную причину сборки. Сообщение от Usaga Было бы здорово увидеть фрагмент кода порождающий такое количество мусора. Я думаю, что его можно будет переделать по-нормальному. Код специфический и нет смысла его сюда выкладывать. А если убрать лишнее, то я только замучаюсь вырезать, да и смысл может быть утерян. Я сделал иначе - создал просто 3 проекта - ConsoleApp. Просто Net462 + ef6, 2) net462 + ef core, 3 - netcore + efcore. Создаём одну простую модель Id, Name. И просто циклом добавляем 100_000 объектов. Потом делаем SaveChanges. И ужасаемся. Прим. речь о постгресе уже не идёт. Это даже без него воспроизводится. Я думал проблема в нём. Если в старой версии я даже не видел увеличения памяти, то в Коре она растёт линейно. Если в нормальной ситуации, любой Dispose даёт выгрузку памяти, то в Core вообще ничего не меняется. Если при удалении объекта и вызове GC есть результат, то в Core мало что меняется. Я бы не стал спорить, если бы это не был Одинаковый код, одинаковый подход. Но в одной версии он всегда давал нормальный результат, а в Коре совершенно другой. Если вы считаете что это вылезли баги, то... ну проверьте тот пример что я сказал. Банально 100_000 объектов, чтобы увидеть заполнение. Я прошуршал даже официальный репозиторий EF. После выхода 2.0 количество жалоб на огромное использование памяти стало частым вопросом. В единичных случаях действительно вроде бы помогают (народ уходит говоря спасибо), но в большинстве это обычные баги с огромными картинками доказательств. Несколько таких сообщений отметили как баг и (я так понял) поставили в работу в версии 3.0. Быстрый пример одного Issue https://github.com/aspnet/Enti... sues/13048 моя ситуация примерно такая же. Один контекст, разные репозитории, смена репозиториев, какие-то действия в них. 1

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	14.09.2018, 06:34	8
	Сообщение от HF Так или иначе "сборщик мусора работает иначе". Это даже видно по диагностики. Если .Net собирает сразу после закрытия зоны видимости (форич, юзинг и т.п.), то кор делает это слишком редко. Это даже больше похоже на временной автосборщик (4 раза за 10 секунд, повторения на всём протяжении), а не на явную причину сборки. Это и есть "работает иначе". Сборка мусора начинается, когда забивается нулевое поколение. Привязок к "форич" и "юзинг" нет. Если в Core размер кучи под нулевое поколение больше, чем в .NET (в котором можно в app.config выбрать из нескольких сборщиков мусора), то забиваться куча будет дольше, соответственно, и сборки будут реже. Так же, Core более эффективно написан (под капотом), там сделали большую работу по уменьшению аллокаций памяти. Это тоже может влиять на скорость забивания кучи. Сообщение от HF Быстрый пример одного Issue Исходя из прочитанного, могу сделать вывод, что EF Core - кусок г***а несмотря на версию 2.1. Посмотрите в сторону Linq To Db. Да, это не такой комбайн как EF \ EF Core, но таких подстав он не делает. 1

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
	14.09.2018, 08:42 [ТС]	9
	Сообщение от Usaga Исходя из прочитанного, могу сделать вывод, что EF Core - кусок г*а несмотря на версию 2.1. Посмотрите в сторону Linq To Db. Да, это не такой комбайн как EF \ EF Core, но таких подстав он не делает. Мне нравится технологическое развитие, я всегда за "движуху". Но в данном случае пока не вижу, чтобы преимущества Core перевешивали так, что я бы сразу без раздумий переходил на него с обычного .Net. Да, он быстрее в разы, да, он мультиплатформен. И на этом всё заканчивается, потому что все те плюсы которые он даёт - за счёт обильных ресурсов, плюс многое не сразу понятно и не так очевидно, а некоторые вещи там работают по умолчанию, хотя нам они не нужны (пример, если я правильно понял, то в EF Core DI там теперь обязательный и всегда там что-то выполняет). Эксперименты я ещё продолжу, может быть и найду решение. Пока ничего не понятно. Сообщение от Usaga Исходя из прочитанного, могу сделать вывод, что EF Core - кусок г*а несмотря на версию 2.1. Посмотрите в сторону Linq To Db. Да, это не такой комбайн как EF \ EF Core, но таких подстав он не делает. Проект развёрнут по задаче на Core/EF Core. Переделывать всю архитектуру нельзя. 0

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	14.09.2018, 08:58	10
	HF, дело не в .NET Core, а именно в EF Core. Судя по описанию подтверждённой проблемы, EF Core кеширует контексты, через репозитории\хелперы, методы которых используются в запросах. Т.е. кешируются именно запросы, но с ними сохраняется и ссылка на объект, чей метод вызывался в запросе (в примере по ссылке: Select()). Если в объекте есть ссылка на контекст, то получаем то, что получаем. Поэтому GC и не может снести задиспоженный контекст, ибо на него есть ссылка в кеше EF-а. Решение: не вызывать методы экземпляров в запросах EF-а. В принципе, не такое уж и трудное и глобальное изменение. Добавлено через 2 минуты У вас такой сценарий? После диспоза и явного вызова GC.Collect() объект контекста остаётся в куче? 0

	17.09.2018, 14:39

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
	14.09.2018, 14:07 [ТС]	11
	Сообщение от Usaga У вас такой сценарий? После диспоза и явного вызова GC.Collect() объект контекста остаётся в куче? Да, так. Но это не сценарий. Мы стали искать причину и решения. Соотственно стали смотреть, что изменится, если удалять объект (.Dispose() или = null). Наоборот с этим подходом больше стало вычищаться, чем если вообще ничего не делать. Сообщение от Usaga Поэтому GC и не может снести задиспоженный контекст, ибо на него есть ссылка в кеше EF-а. Решение: не вызывать методы экземпляров в запросах EF-а. В принципе, не такое уж и трудное и глобальное изменение. Не уверен что понял правильно, уточните пожалуйста примером о чём речь - "методы экземпляров в запросах EF-а". 0

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
	16.09.2018, 17:40 [ТС]	13
	Если кому-то это будет интересно и полезно, то вот мой рассказ. "Тысяча" тестов показала, что новый Core + Core EF создают нехорошую ситуацию с использованием памяти. Причина поисков: при создании объектов и последующей записи через AddRange, SaveChanges начинает линейно заполнять память и после окончания выполнения память не восстанавливается. Подозрения что Dispose не выполняется, соответственно оставляя всё в памяти. Тестовый солюшен: - проект - модель данных, проекты ConsoleApp, ConsoleCoreApp, WebCoreApp - модель, состоит из User, Permission. User имеет связь с Permission. Модели "бедные", без какой-либо реализации. - dbContext - EF + mssql (localdb) - производится запись созданных 100_000 User с заполненным Permission - цикл производится 3 раза, для сравнения и ожидания очистки памяти - анализ памяти через снапшоты VS Diagnostic Итоговые результаты: - EF Core затягивает за собой хвалёный Microsoft.Extension.DependencyInjection и везде его использует. То есть даже если у нас в проекте не будет использован DI, то он всё равно есть, как суслик. При анализе памяти он обнаруживается везде где только можно. В том числе как какая-то связь с моделью данных. - Как оказалось, на самом деле DI выполняет обещанный Dispose везде, где должен, как и обещалось в документации Microsoft. Это конечно большое удобство и плюс в его честь. - но минус в том, что в памяти создаётся просто огромное (на мой взгляд) количество объектов, которые возможно управляют состоянием модели и т.п. операций EF. Например для 3000 добавленных объектов появилось кроме этих объектов ещё 5 раз по 3000 каких то других объектов, связанных с моделью. В случае с 100000 объектами это соотственно память * 5. - если проект не Web, то управлять выгрузкой памяти нужно обязательно, т.к. автоматическим Dispose занимается DI, а выгружается он только когда приложение закроется. Главное: - память почти никогда не выгружается на начальное состояние - но отладчик показал, что на самом деле объектов вычищаются! т.е. делаем несколько снапшотов и видим что при окончании всего жизненного цикла приложения, все диспозы выполнились и количество объектов в снапшоте равно количеству добавленных. Но при этом оперативная память остаётся на заполненном уровне. - при выполнении проектов в Release режиме, память вообще ведёт себя неадекватно и я даже не понял зависимости Ещё осталось провести тесты с полным забиванием памяти, в надежде что он сам начнёт чистить её при необходимости. Но...сомнительно. Итог: - EF Core и DependencyInjection страшное зло -- EF Core использует очень много памяти. Наверное это кэширование и какие-нибудь эффективные правила, но за на счёт. В сравнении с EF6 ровно в два раза. + EF Core для AddRange использует MERGE - но не с большим количеством записей. Но тоже большой плюс, не нужно использовать сторонние BULK библиотеки. - всегда желательно управлять внутренними ресурсами. Использовался список - нужно его явно зачистить и удалить. Больше шансов что быстрее выгрузится. 1

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	16.09.2018, 17:58	14
	HF, самое прикольное, что люди жалуются и на наличие "классической" болячки EF-а - разогрев. В EF6.X он был конским. В EF Core он стал лучше, но и функционала в нём меньше. И на то, что люди жалуются на разогрев больших контекстов длящийся МИНУТАМИ, разрабы отвечают так: Миниатюры 1

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	16.09.2018, 18:00	15
	Т.е. на жалобы о том, что продукт является неюзабельным на практике дерьмом, авторы отвечают: "у нас есть более приоритетные задачи". Для кого оно пишется - не понятно. Если есть возможность, то используйте что-нибудь другое. Да, не так удобно, но и подстав будет меньше. 1

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
	16.09.2018, 19:05 [ТС]	16
	Сообщение от Usaga Если есть возможность, то используйте что-нибудь другое. Да, не так удобно, но и подстав будет меньше. У нас проект на Core 2.0 + EF Core 2.0. Мы просто решили что пора наверное обновиться в пользу улучшения так сказать. И начали тесты проводить. И первые же наблюдения выявили такие странности. Решил от любопытства выяснить - это у нас неправильно что-то, или обновление не такое уж и решение. Сообщение от Usaga самое прикольное, что люди жалуются и на наличие "классической" болячки EF-а - разогрев. В EF6.X он был конским. В EF Core он стал лучше, но и функционала в нём меньше. И на то, что люди жалуются на разогрев больших контекстов длящийся МИНУТАМИ Сообщение от Usaga Т.е. на жалобы о том, что продукт является неюзабельным на практике дерьмом, авторы отвечают: "у нас есть более приоритетные задачи". Для кого оно пишется - не понятно. Это подтверждает моё мнение (где-то темка была с обсуждением), что Core пока продукт абсолютно не юзабельный, так как находится на стадии активного развития. И каждая версия может кардинально отличаться друг от друга. Плюс к этому, если раньше считалось что Core это улучшение обычного Net, то сейчас уже чётко видно, что это совсем другой продукт со своими багами и глюками, которых в простом Net - нет. Скоро 3.0. Может быть все усилия бросили в эту ветку? Но если старые проблемы перенесут туда, то это будет жуткая жопа. Ещё уточню, что я проводил тесты с проектами ConsoleApp + Core. Там такая же ситуация с памятью, но там хотя бы Dispose и GC.Collect явно отрабатывают и вычищают всё. Можно тему перенести в форум "C#: Базы данных, ADO.NET". Там ему больше места, чем тут. Изначально я считал что проблема в самом Core или AspCore. 0

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	17.09.2018, 03:42	17
	.NET Core и ASP.NET Core - зрелые продукты. А вот EF Core выглядит, что разрабатывается "на сдачу", чисто чтобы было. Косяки "классического" EF были известны уже давно, и это не производительность (она была приемлемой). Но в EF Core приоритет отдаётся чему попало. Попробуйте EF Core 2.2, который недавно вышел в Preview 2. Может там получше стало с памятью. Версия 2.2 у них идёт как корректирующая, без новых фич, чисто исправление багов. А вообще, ребята работающие над EF Core сказали недавно, что ведут работу по портированию EF 6 (будущая версия EF 6.3) на .NET Core 3.0. Объясняется тем, что так людям будет легче потихоньку мигрировать на Core, что больше звучит как признание того, что EF Core у них не получается нормальным продуктом. 0

@HF 1163 / 749 / 181 Регистрация: 09.09.2011 Сообщений: 2,314 Записей в блоге: 2
	17.09.2018, 14:33 [ТС]	18
	Сообщение от Usaga А вообще, ребята работающие над EF Core сказали недавно, что ведут работу по портированию EF 6 (будущая версия EF 6.3) на .NET Core 3.0. Объясняется тем, что так людям будет легче потихоньку мигрировать на Core, что больше звучит как признание того, что EF Core у них не получается нормальным продуктом. Не хотел тему вопроса в тему обсуждения превращать, но чем более читаю и разбираюсь, тем больше отвращение. Вот что ещё пишут в комментариях. I’m looking forward to 3.0 with regard to improvements in the LINQ provider, or any improvements to the LINQ provider in general. That is one of the most important parts of EF IMHO. I am still stuck using EF 6 for some of my queries. It would be nice if one day EF Core could handle all the queries that EF 6 does without kicking off an unacceptable number of N+1 queries. Some of the EF 6 queries looked horrific in terms of tons of joins, but, actually worked acceptably. Будем ждать и надеяться 3.0. Вроде бы уже скоро. 0