C # Что бы случилось с GC, если я запустил процесс с приоритетом = RealTime?

Question

У меня есть приложение на C #, которое работает с приоритетом RealTime. Все было хорошо, пока я не сделал несколько беспокойных изменений за последние 2 дня. Теперь у него заканчивается память за несколько часов.

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

Мой вопрос - что может случиться с GC, когда он пытается собрать объекты в приложении с приоритетом RealTime (есть также хотя бы один поток, работающий с самым высоким приоритетом потока)?

( P.S. по приоритету в реальном времени я имею в виду Process.GetCurrentProcess (). PriorityClass = ProcessPriorityClass.RealTime )

Извините, забыл сказать. ГХ в режиме сервера

Answer 1

ГХ работает в вашем процессе и, следовательно, имеет тот же приоритет. На его способность к сбору не влияет PriorityClass, с которым работает ваше приложение.

Эта утечка памяти почти наверняка вызвана тем, что вы держитесь за корень растущего графа объектов, который не позволяет GC собирать его.

Answer 2

Скорее всего, GC не может собрать их, потому что где-то у вас еще есть ссылка. Попробуйте профилировать ваше приложение с помощью профилировщика памяти (у RedGate есть хороший, вам следует попробовать пробную версию), чтобы выяснить, почему GC не будет собирать ваши объекты.

Answer 3

Я бы серьезно не рекомендовал запускать какие-либо программы в качестве приоритета RealTime.По сути, все, что работает с приоритетом RealTime, работает с более высоким приоритетом, чем GUI или даже диспетчер задач Windows ... и, таким образом, может блокировать самого пользователя.

Раймонд Чен говорил об этом последнемнеделя .

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

Answer 4

Я действительно сомневаюсь, что причиной вашей проблемы является приоритет в реальном времени. Я предполагаю, что в паре изменений, о которых вы упомянули, вы теряете память где-то (что в C # обычно означает сохранение ссылок на объекты, которые больше не нужны). Вы можете использовать профилировщик памяти, использовать WinDbg с SOS (см., Например, http://msdn.microsoft.com/en-us/magazine/cc163528.aspx) или просто взглянуть на эти изменения и попытаться осмотреть проблему.

Answer 5

Вместо изменения приоритета потока и, возможно, блокировки вашей системы, вы должны использовать профилировщик памяти, чтобы определить реальную причину проблемы.Вы также можете использовать системный монитор для проверки счетчиков производительности в категории .NET CLR Memory, чтобы увидеть, сколько памяти выделено, сколько осталось после сборки мусора и т. Д.

Answer 6

Сборка мусора Потоки по-разному, в зависимости от типа системы, на которой вы настроили их запуск. На простой рабочей станции каждый отдельный поток будет размещать сборщик мусора, но одновременно может быть размещен только один поток. Если он настроен для работы на сервере, сборка мусора будет размещена в отдельном потоке.

http://msdn.microsoft.com/en-us/library/ee787088.aspx#generations

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

Или, возможно, у вас есть другая проблема.