5

Я использую профилировщик памяти ANTS для диагностики увеличения утечки памяти, с которой сталкиваюсь в одном из моих приложений .NET 2.0. я принял 7 снимки процесса в течение 7,5 часов, а вот табличное представление полученных данных -Использование памяти приложений .NET - высокая неиспользованная .NET и неуправляемая память и фрагментация

enter image description here

G1 reprsents поколение 1 размер и G2 поколения 2 размера. За исключением неуправляемого пространства и частных байтов, все остальные значения находятся в МБ.

Мои вопросы -

  1. Почему такая высокая неиспользованными .NET пространство, даже если размеры кучи низкие?

  2. Моя куча больших объектов достигает максимум 2 МБ, а в течение последних 3 моментальных снимков остается на 96 КБ. Тогда почему такие большие большие фрагменты, и они отвечают за высокое неиспользуемое пространство?

  3. Неуправляемое пространство постоянно увеличивается. Отвечает ли это за увеличение количества личных байтов во времени?

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

+0

Это может быть результат пребывания объектов в памяти. Возможно, вы должны убедиться, что все используемые объекты хорошо расположены, поскольку постоянное повторное инициализация будет означать выделение большего объема памяти. Который может быть причиной фрагментации также –

+0

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

+0

Правильно ли размещен второй массив? GC в LOH - очень редкое событие.Возможный сценарий заключается в том, что ваш второй массив распределяется перед GC, поэтому возможный сценарий может выглядеть так: [1,2] (начало приложения) [1,2,2] (второй массив получает перераспределение) Когда вы получите GC в LOH, ваш LOH будет выглядеть так: [1,0,0,0,0,2] , тогда вы начнете выделять второй массив еще раз и получите: [1, 2,0,0,0,2] Если второй массив не имеет постоянной длины, все может быть еще хуже. Идея не позволяет много перераспределения в LOH. – Alex

ответ

2

Как Алекс уже отмечал очень хорошее объяснение проблемы класса большой фрагментации объекта кучи найден здесь:

https://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/

Проблема хорошо известна в Dev Team .NET FX и постоянно была разработана в. Существует хорошая вероятность того, что симптомы исчезнут с использованием более поздних выпусков FX.

Начиная с .NET 4.5.1 будет метод GC вызов даже компактнее ЛОХ: http://blogs.msdn.com/b/mariohewardt/archive/2013/06/26/no-more-memory-fragmentation-on-the-large-object-heap.aspx Однако нахождение первопричиной LOHF будет способ более эффективен, чем просто протерев его из кучи тратить тонн of ms's

Сообщите мне, если вам нужна дополнительная информация о том, как изолировать такие эффекты.

Seb