После долгого запуска процесса .net я вижу большую разницу между памятью, которую знает GC, и рабочим набором процесса.
Значения, которые я отслеживаю, - это GC.GetTotalMemory (false) и Process.WorkingSet.
Если я отмечу в «диспетчере задач» (или с помощью инструмента SysInternals) значение WorkingSet (Process) и то, что показано в «диспетчере задач», не совпадают, ноони как-то близки (скажем, 100 МБ в диспетчере задач, 130 в WorkingSet), но меня шокирует то, что GC.GetTotalMemory (false) похож на 40 МБ или около того.
Я запускал несколько разчерез профилировщики (мой любимый ants memory profiler из redgate ), и там легко проверить, что есть значение, называемое «свободная память», которое обычно является разницей между тем, что «видит» GC, и тем, что ОСвидит (хорошо, плюс загруженные библиотеки DLL и т. д.).
Пара вопросов:
Есть ли способ программно контролировать эту "свободную память GC".Да, я мог бы использовать профилировщик, но в длительном процессе это не так просто.
Если ваш процесс выполняется в течение длительного времени, выделяет много памяти, а затем освобождает ее (а выделение означает тысячи или миллионы объектов (не так просто, как большое и бесплатное выделение), проблема заключается в том, что оно никогда не «сократится» до низкого значения, несмотря на то, что значения GC низкие и правильные.Есть ли способ это исправить?Возможно, что-то сломалось в моем процессе, но он был профилирован несколько раз за эти годы, и это не похоже на утечку.
Спасибо