[Обновление - 30 сентября 2010 г.]

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

1) Используйте профилировщик памяти (для начала попробуйте CLR Profiler) и найдите подпрограммы, которые используют max mem, и настройте их, например, повторно используйте большие массивы, постарайтесь свести к минимуму ссылки на объекты.

2) Если возможно, выделите небольшие объекты (менее 85 КБ для .NET 2.0) и используйте пулы памяти, если вы можете избежать высокой загрузки ЦП сборщиком мусора.

3) Если вы увеличиваете количество ссылок на объекты, вы обязаны разыменовывать их одинаковое количество раз. Вы будете спокойны, и код, вероятно, будет работать лучше.

4) Если ничего не работает, а вы все еще не понимаете, используйте метод исключения (комментарий / пропуск кода), чтобы узнать, что потребляет больше всего памяти.

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

Надеюсь, что это поможет!

[Оригинальный вопрос]

Привет!

Я работаю в C #, и моя проблема не связана с памятью.

Я прочитал отличную статью о LOH здесь ->http://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/

Классно читать!

А также,http://dotnetdebug.net/2005/06/30/perfmon-your-debugging-buddy/

Моя проблема:

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

Я попытался CLR Profiler для анализа использования памяти. Это было полезно в:

Показывая мне, кто выделил огромные куски памяти

Какой тип данных используется максимальная память

Но как CLR Profiler, так и счетчики производительности (поскольку они используют одни и те же данные) не смогли объяснить:

Числа, которые собираются после каждого запуска приложения - как понять, есть ли улучшения?!?!

Как сравнивать данные о производительности после каждого прогона - хорошо или плохо меньше или больше число конкретного счетчика?

Что мне нужно:

Я ищу советы по:

Как освободить (да, верно)удалось объекты типа данных (например, массивы, большие строки) - но не путем вызовов GC.Collect, если это возможно. Я должен обрабатывать массивы байтов длиной около 500 КБ (неизбежный размер :-() время от времени.

Если происходит фрагментация, как сжимать память - так как кажется, что .NET GC не очень эффективно делает это и вызывает OOM.

Кроме того, что конкретно является лимитом 85 КБ для LOH? Это размер объекта общего размера массива? Это не очень понятно для меня.

Какие счетчики памяти могут определить, действительно ли изменения кода снижают шансы OOM?

Советы, которые я уже знаю

Установите для управляемых объектов значение null - пометьте их как мусор, чтобы сборщик мусора мог их собрать. Это странно - после установкиСтрока [] объект к нулю,# байт во всех кучах выстрелил

Избегайте создания объектов / массивов> 85 КБ - это не в моем контроле. Таким образом, может быть много LOH.

3.

Memory Leaks Indicators:

# bytes in all Heaps increasing
Gen 2 Heap Size increasing
# GC handles increasing
# of Pinned Objects increasing
# total committed Bytes increasing
# total reserved Bytes increasing
Large Object Heap increasing

Моя ситуация:

У меня есть 4 ГБ, 32-битный компьютер с Wink 2K3 сервер SP2 на нем.Я понимаю, что приложение может использовать <= 2 ГБ физической памятиУвеличение размера виртуальной памяти (файла подкачки) в этом сценарии не влияет.

В связи с проблемой OOM я сосредоточился только на счетчиках, связанных с памятью.

Пожалуйста посоветуй!Мне действительно нужна помощь, потому что я застрял из-за отсутствия хорошей документации!