Инструменты для анализа объема памяти встроенных DLL и сборок, загруженных в процесс?

У меня есть процесс хранения 130 МБ памяти в соответствии с диспетчером задач, только с 11 МБ живых .NET-объектов в соответствии с dotTrace, поэтому мне интересно что происходит с другими 120 МБ??

Мне нужен инструмент для перечисления сборок и встроенных DLL файлов, загружаемых в процесс, получения размера обрабатываемых изображений и для каждой сборки измерять объем памяти методов JITed.

ListDlls из SysInternal частично выполняет эту работу. Но он не измеряет размер кода JITed, и он просто предоставляет необработанные данные. В идеале я бы хотел, чтобы пользовательский интерфейс анализировал и суммировал эти данные.

Недавно команда Visual Studio сообщила о проведении такого анализа с помощью инструмента PerfView. Об этом говорится в сообщении в блоге Visual Studio 11 Beta Performance Part # 1, раздел: Самые большие виртуальные машины VM - DLL. У кого-то есть опыт и отзывы, анализирующие исходные Dll и сборки с помощью PerfView?

За исключением ListDlls и PerfView, вы бы рекомендовали какой-либо другой инструмент?

Хорошо, VMMAP, рекомендованный Саймоном Мурье, кажется более подходящим инструментом для этой задачи. VMMAP показывает, что основная часть рабочей памяти набора входит в управляемый стек (113 МБ в зеленом ниже), поэтому проблема больше связана с объектами .NET, чем с неуправляемой памятью. Зеленая кривая зуба, это всего лишь график сеансов погрузки/разгрузки. По некоторым причинам мои первые меры были совершенно неправильными:

dotTrace говорит мне, что у меня есть 41 МБ объектов .NET,
WMMAP показывает рабочий набор из 180 МБ (диспетчер задач показывает аналогичное число)
WMMAP показывает 113 МБ управляемой кучи, выделенной GC. 90MB этой управляемой памяти кучи находится в рабочем наборе:

Итак, мой план:

Определите, почему GC выделяет 113 МБ управляемой кучи для 41 МБ объектов .NET? (такие числа нормальны? Это связано с высокой фрагментацией?)
Работа над сокращением этого 41 МБ набора выделенных .NET-объектов!

Ответ 1

Поскольку вы упоминаете список ListSlls sysinternals, есть еще один инструмент под названием Process Explorer, который содержит тонны информации и намного лучше, чем ListDlls ( вы хотите убедиться, что у вас есть последние версии, которые также содержат много информации о .NET, поддерживают 64-битные и 32-битные процессы и т.д.).

Для каждого процесса вы можете иметь одновременные представления неуправляемой памяти (private bytes et al.) и управляемой памяти (коллекции GC, куча больших объектов и т.д.), отображаемые в столбцах или каждом процессе.

Еще один классный инструмент из sysinternals - VMMAP. Это утилита анализа памяти процесса и показывает разбивку различных типов виртуальных и физических типов памяти.

Что касается вопроса 120Mb, вы действительно хотите проверить все неуправляемые библиотеки DLL, которые вставляются в ваш процесс, и не являются частью стандартной установки Windows или стандартного набора DLL-процессов. Разумеется, для таких распределений большого размера я бы, в первую очередь, отслеживал графические компоненты, поскольку они, как известно, выделяют большие куски памяти (особенно если вы говорите об инструменте, таком как NDepend, который является графическим). Process Explorer также может отслеживать количество объектов GDI и USER.

В теме GDI имеется бесплатный инструмент с именем GDIView, который содержит информацию о объектах GDI, выделенных для каждого процесса.

Ответ 2

Я рекомендую SciTech.NET Memory Profiler. Инструмент ориентирован прежде всего на профилирование использования памяти .NET, например, на поиск утечек памяти .NET или определение зон с большим давлением памяти. В то время как это не основное использование, оно также имеет более простое отображение собственной памяти, включая размер JIT-кода для загружаемой библиотеки. Я уверен, что вы сможете найти, откуда эти 120 МБ, с такой информацией.

Ответ 3

Я использую RedGate ANTS.NET Developer Bundle для этих проблем. "Профилятор памяти" позволяет идентифицировать утечки памяти (например, объекты зомби) и делать снимки использования памяти. Затем вы сможете сравнивать классы и экземпляры между двумя моментальными снимками. Вы можете отслеживать ссылку на экземпляр в дереве и легко просматривать верхний объект, который поддерживает ссылку.

Кроме того, Performance Profiler предоставляет профилирование кода для выявления узких мест и использования ЦП.

В течение многих лет это помогло нам найти проблемы с приложениями в течение нескольких минут.