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

Question

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

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

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

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

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

---

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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