Счетчики производительности памяти
[Обновление - 30 сентября 2010 г.]
Поскольку я много изучал эту и связанные с ней темы, я напишу все советы, которые я почерпнул из своего опыта, и предложения, представленные в ответах здесь-
1) Используйте профилировщик памяти (для начала попробуйте CLR Profiler) и найдите процедуры, которые потребляют максимум памяти, и точно настройте их, например, повторно используйте большие массивы, постарайтесь свести ссылки на объекты к минимуму.
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 для анализа использования памяти. Это было полезно в следующих случаях:
Показал мне, кто выделял огромные блоки памяти
Какой тип данных использовал максимальную память
Но ни профилировщик CLR, ни счетчики производительности (поскольку они используют одни и те же данные) не смогли объяснить:
Цифры, которые собираются после каждого запуска приложения - как понять, есть ли улучшения?!?!
Как мне сравнить данные производительности после каждого запуска - меньше / больше число конкретного счетчика хорошо или плохо?
Что мне нужно:
Я ищу советы по:
Как освободить (да, верно) управляемые объекты типа данных (например, массивы, большие строки) - но не путем вызова GC.Collect, если возможно. Мне время от времени приходится обрабатывать массивы байтов длиной, например, 500 КБ (неизбежный размер :-().
Если происходит фрагментация, как сжать память - поскольку кажется, что .NET GC не очень эффективно это делает и вызывает OOM.
Кроме того, каков именно предел в 85 КБ для LOH? Это размер объекта общего размера массива? Мне это не очень ясно.
Какие счетчики памяти могут определить, произошли ли изменения кода действительно снижает вероятность OOM?
Советы, которые я уже знаю
Установите для управляемых объектов значение null - пометьте их как мусор - чтобы сборщик мусора мог их собрать. Это странно - после установки объекта string [] на нуль, # байтов во всех кучах резко выросли!
Избегайте создания объектов / массивов> 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
Моя ситуация:
- У меня есть 32-разрядная машина объемом 4 ГБ с сервером Wink 2K3 SP2.
- Я понимаю, что приложение может используйте
- Увеличение размера виртуальной памяти (файла подкачки) не имеет никакого эффекта в этом сценарии.
В связи с проблемой OOM я сосредотачиваюсь только на счетчиках, связанных с памятью.
Пожалуйста, посоветуйте! Мне действительно нужна помощь, так как я застрял из-за отсутствия хорошей документации!