Как использовать файл дампа для диагностики утечки памяти?

Question

У меня есть служба .NET с обычным рабочим набором около 80 МБ. Во время недавнего нагрузочного теста процесс достиг 3,5 ГБ памяти, из-за чего на всей машине было мало физической памяти (3,9 из 4 ГБ), и память не освобождалась долго после остановки нагрузочного теста. Используя диспетчер задач, я взял дамп-файл процесса и открыл его в Visual Studio 2010 с пакетом обновления 1 (SP1) и смог начать отладку на нем.

Как диагностировать проблему с памятью? У меня есть dotTrace Memory 3.x, поддерживает ли он профилирование памяти для файлов дампа? Если нет, помогут ли функции профилирования памяти в Visual Studio 2010 Premium (в настоящее время у меня есть Professional)? Может ли WinDbg помочь?

ОБНОВЛЕНИЕ: Новый Visual Studio 2013 Ultimate теперь может напрямую диагностировать проблемы с памятью с помощью файлов дампа. Подробнее см. в этом блоге .

Answer 1

Установить WinDbg.Вы должны убедиться, что вы получаете правильную версию x86 или x64 в зависимости от вашего дампа.Вот прямая ссылка на загрузку для x86.

На этом вы должны убедиться, что вы взяли правильный дамп.Вы можете использовать диспетчер задач для создания файла дампа (щелкните правой кнопкой мыши по процессу -> Создать файл дампа).Если вы используете 64-разрядную версию, а ваш процесс - x86, используйте 32-разрядную версию диспетчера задач (C: \ Windows \ SysWOW64 \ taskmgr.exe), чтобы получить файл дампа.См. мою статью для получения дополнительной информации о получении файлов дампа, например, если вы используете XP и вам нужно использовать windbg для создания файла дампа.

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

Я предполагаю, что вы используете .NET4, если вы можете открыть дамп в Visual Studio.Вот очень краткое руководство, которое поможет вам работать с вашим dmp-файлом:

1) Запустите WinDbg, установите путь к символам (Файл -> Путь поиска символов) на

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

2) Откройте Crash dump или перетащите файл .DMP на WinDbg.

3) введите его в командном окне

.loadby sos clr

(FYI, для .NET 2, команда должнабыть .loadby sos mscorwks)

4) затем введите этот

!dumpheap -stat

, в котором перечислены типы объектов и их количество.выглядит примерно так:

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

Есть еще много больше, чем виндбг, Google - ваш друг.

Answer 2

Обычно, если у вас есть утечка в управляемом приложении, это означает, что что-то не собирается.К общим источникам относятся

• Обработчики событий: Если подписчик не удален, издатель будет удерживать его.

• Статика

• Финализаторы: заблокированный финализатор не позволит потоку финализатора запускать любые другие финализаторы и, таким образом, предотвращает сбор этих экземпляров.

• Аналогично, заблокированный поток будет удерживатьна каких корнях он держит.Конечно, если у вас есть заблокированные потоки, которые, вероятно, повлияют на приложение на нескольких уровнях.

Для устранения неполадок необходимо проверить управляемую кучу.WinDbg + SOS (или PSSCOR) позволит вам сделать это.Команда !dumpheap -stat выводит список всей управляемой кучи.

Необходимо иметь представление о количестве экземпляров каждого типа, ожидаемых в куче.Как только вы найдете что-то странное, вы можете использовать команду !dumpheap -mt <METHOD TABLE> для вывода списка всех экземпляров данного типа.

Следующим шагом является анализ корня этих экземпляров.Выберите один наугад и сделайте !gcroot на этом.Это покажет, как этот конкретный экземпляр укоренен.Ищите обработчики событий и закрепленные объекты (обычно представляют статические ссылки).Если вы видите там очередь финализатора, вам нужно проверить, что делает поток финализатора.Для этого используйте команды !threads и !clrstack.

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

Другие источники утечек включают: Сборки, которые не выгружены, и фрагментация кучи больших объектов.SOS / PSSCOR также может помочь вам найти их, но пока я пропущу детали.

Если вы хотите узнать больше, я рекомендую блог Тесс .Я также снял несколько видео о том, как использовать WinDbg + SOS ( здесь и здесь ).

Если у вас есть возможность отладки процесса во время его выполнения, я рекомендую использовать PSSCOR вместо SOS.PSSCOR - это, по сути, частная ветвь источников SOS, которая была дополнена дополнительными командами, а также улучшены многие из существующих команд SOS.Например, PSSCOR-версия команды !dumpheap имеет очень полезный дельта-столбец, который значительно облегчает устранение утечек памяти.

Чтобы использовать его, вам нужно запустить процесс, подключить WinDbg, загрузить PSSCOR и выполнить !dumpheap -stat.Затем вы позволяете процессу запускаться снова, чтобы распределение было выполнено.Прервите выполнение и повторите команду.Теперь PSSCOR покажет вам количество экземпляров, которые были добавлены / удалены со времени предыдущей проверки.

Answer 3

Начиная с версии 2017.2 JetBrains dotMemory поддерживает анализ дампов памяти Windows со всем своим мощным и необычным графическим интерфейсом.

Answer 4

http://msdn.microsoft.com/en-us/library/ee817660.aspx

Здесь есть руководство Microsoft.Тем не менее, это слишком сложно для начинающих.

dotTrace может генерировать графики визуальной памяти (лучше, чем WinDbg), но никогда не использовать его для дампов.