Всем привет!
Столкнулись с такой проблемой: по мере работы .net 6.0 сервис, запущенный как Windows-служба, отъедает на машине все больше и больше потоков (см. Task Manager, колонка Threads) и не убивает их. Web API приложения обслуживает много несложных запросов. Вроде бы ничего некорректного в коде нет: много где внутренние сервисы вызываются через DI, using, применяются финализаторы, сборка мусора и т.п. Но периодически кол-во потоков начинает зашкаливать и вообще непонятно, куда смотреть.
Показатель Process.GetCurrentProcess().Threads.Count действительно очень большой.
Методы типа ThreadPool.SetMaxThreads() ничего не дают ((
В какую сторону смотреть?
Help!
Принудительную сборку мусора через GC.Collect() пробовали применять? Если не помогает, значит, где-то остались ссылки и есть утечка памяти, иначе Dispose вызывается не везде в Вашем коде.
Возможно, у вас не отрабатывает сборка (если отбросить ошибки в коде). Существует редкая ошибка утечки памяти, когда контекст переменной != контекст сборки мусора. Попробуйте избавиться от создания объектов внутри циклов и условий, а перенести всё это в отдельные функции.
Принудительную сборку мусора через GC.Collect() пробовали применять? Если не помогает, значит, где-то остались ссылки и есть утечка памяти, иначе Dispose вызывается не везде в Вашем коде.
Смотреть в сторону разницы: Process.GetCurrentProcess().Threads.Count и ThreadPool.ThreadCount
Скорее всего какой-то сервис создает множество потоков (ручных) и держит ссылки на них, т.к. поток это объект ядра и он должен быть уничтожен когда на него перестают ссылаться, либо это просто поток, который не завершатся (while (true) какой-нибудь)
да, разница между Process.GetCurrentProcess().Threads.Count и ThreadPool.ThreadCount как раз колоссальная. Первый зашкаливает (80+ тыс), второй = 10-15.
Простой