Как можно исследовать управляемую "кучу" в приложении.NET для идентификации возможной оптимизации памяти?
У нас есть заявление.NET, которое наши клиенты рассматривают слишком большими для массового развертывания, и мы хотели бы понять то, что способствует нашему объему потребляемой памяти и является им возможный сделать немного лучше, полностью не отказываясь от.NET и wpf.
Мы интересуемся улучшением и Общий Размер и Частный Рабочий набор (pws). В этом вопросе я просто хочу посмотреть на pws. VMMap обычно сообщает о pws 105 МБ. Из этого 11 МБ являются изображением, 31 МБ "куча", 52 МБ управляемая "куча", 7 МБ частные данные, и остальное - стек, таблица страниц и т.д.
Самый большой приз здесь является управляемой "кучей". Мы можем объяснить приблизительно 8 МБ manged "кучи" непосредственно в рамках нашего собственного кода, т.е. объектов и окон, которые мы создаем и управляем. Остальное - возможные объекты.NET, созданные элементами платформы, которую мы используем.
То, что мы хотели бы сделать, определяют, какой элемент платформы составляют, какая часть этого использования и потенциально ре проектирует нашу систему для предотвращения их использования, если это возможно. Кто-либо может предложить, как это расследование может быть сделано?
Дальнейшее разъяснение:
Я использовал много инструментов до сих пор, включая превосходных профилировщиков МУРАВЬЕВ и WinDbg с SOS, и они действительно позволяют мне видеть, что объекты в управляемой "куче", но реального интереса вот не 'Что?', но, 'Почему?' Идеально я хотел бы смочь сказать, "Ну, там 10 МБ объектов, созданный здесь, потому что мы используем WCF. Если мы пишем наш собственный собственный транспорт, мы могли бы сохранить 8 МБ из этого с x качественным риском и y усилием по разработке".
Выполнение gcroot на 300 000 + объекты не возможно.
4 ответа
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 Профилировщик и это руководство по использованию полезны.
Я использую .NET Memory Profiler . Это также используется некоторыми командами Microsoft внутри компании, о чем говорится в подкасте PDC.
Профилировщик CLR также графически показывает память, выделенную по типам в куче.
Любой приличный профилировщик памяти покажет вам эту информацию. Не стоит возиться с бесплатным CLR Profiler, он не стоит вашего времени, найдите достойный инструмент стороннего производителя. Вы найдете их упоминание в этой теме.