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

Question

У нас есть приложение .NET, которое наши клиенты считают слишком большим для массового развертывания, и мы хотели бы понять, что влияет на наш объем памяти и можно ли добиться большего, не отказываясь от .NET и wpf.

Мы заинтересованы в улучшении как общего размера, так и частного рабочего набора (pws). В этом вопросе я просто хочу посмотреть на pws. VMMap обычно сообщает pws 105 МБ. Из этого 11 Мб - образ, 31 Мб - куча, 52 Мб - управляемая куча, 7 Мб - личные данные, а остальное - стек, таблица страниц и т. Д.

Самый большой приз здесь - управляемая куча. Мы можем учесть около 8 МБ управляемой кучи непосредственно в нашем собственном коде, то есть объектах и ​​окнах, которые мы создаем и которыми управляем. Остальные предположительно .NET объекты, созданные элементами инфраструктуры, которые мы используем.

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

Дополнительные уточнения:

До сих пор я использовал ряд инструментов, в том числе отличные профилировщики ANTS и WinDbg с SOS, и они позволяют мне видеть объекты в управляемой куче, но реальный интерес здесь - не «Что?», А 'Зачем?' В идеале я хотел бы иметь возможность сказать: «Ну, здесь создано 10 МБ объектов, потому что мы используем WCF. Если мы напишем собственный нативный транспорт, мы могли бы сэкономить 8 МБ из этого с x риском для качества и y усилиями по разработке».

Выполнение gcroot для 300 000+ объектов невозможно.

Answer 1

WinDbg может быть полезным инструментом для вас. Он поставляется с Средствами отладки для Windows .

После запуска приложения вы можете подключить WinDbg и изучить управляемую кучу. (Или вы можете взять дамп памяти и исследовать его в автономном режиме). Он сможет очень быстро определить типы объектов, занимающих наибольшие объемы памяти.

Сначала вам нужно загрузить расширение SOS , которое позволяет отлаживать управляемые приложения:

.loadby sos mscorwks

Затем вы можете использовать !dumpheap для получения информации о куче, переключатель -stat дает общую информацию о куче, по которой выделяются типы:

!dumpheap -stat

Параметр -type предоставляет конкретную информацию о выделенных экземплярах указанного типа:

!dumpheap -type System.String

Существует множество других команд, которые могут оказаться полезными, например:

• !gcroot - чтобы проследить за выделенным объектом обратно в корень, чтобы выяснить, почему он находится в памяти.
• !dumpobj - выгрузить определенный объект, чтобы вы могли увидеть его содержимое.
• !EEHeap - дать общую статистику кучи.

MSDN имеет полный список команд SOS и их переключателей.

WinDbg - довольно сложный инструмент, но в Интернете есть множество руководств и руководств, если вы ищете, чтобы помочь вам начать работу. В качестве альтернативы я могу порекомендовать книгу Джона Роббинса Отладка приложений Microsoft .NET 2.0 , в которой подробно описаны возможности отладки .net в WinDbg и SOS.

Вместо этого вы можете загрузить расширение SOS в visual studio, введя его в непосредственное окно, после чего вы сможете использовать команды SOS непосредственно в непосредственном окне VS:

.load SOS.dll

Вы также можете найти CLR Profiler и это Руководство по использованию полезным.

Answer 2

Новый инструмент - PerfView, который может отображать справочное дерево, а также выполнять различие

Answer 3

Я использую .NET Memory Profiler . Это также используется некоторыми командами Microsoft для внутренних целей, как сказано в подкасте PDC.

Answer 4

CLR-профилировщик также показывает графически выделенную память по типу в куче.

Answer 5

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