Могу ли я запустить сборку мусора .NET из WinDbg?
Я изучаю, почему управляемый процесс использует много памяти. Есть ли способ запустить GC.Collect(3) из WinDbg, чтобы я мог сосредоточиться на фактическом распределении памяти?
Ответы 4
Я не думаю, что есть способ запустить сборку мусора .NET из WinDbg, но я также не думаю, что это необходимо.
См. Лакомые кусочки производительности Рико Мариани - Отслеживание утечек управляемой памяти (как найти утечку сборщика мусора) для получения информации о том, как узнать, какие вещи находятся в вашей куче.
Дополнительные возможно полезные ссылки:
В этом нет необходимости, потому что информация Рико Мариани об отслеживании утечек управляемой памяти описывает процесс определения того, что может быть утечкой или что находится в куче в любой точке вашего приложения, без необходимости принудительного создания сборщика мусора.
Не будете ли вы часто сталкиваться с проблемой на шаге 7 (из сообщения в блоге Рико Мариани), если у вас есть много объектов, которые могут быть GC'd? Похоже на обычное разочарование, когда! Gcroot объект за объектом и вообще не находит цепочек ссылок.
@IV Согласен - это настоящая боль. Я часто использую флаг «disposed» в качестве прокси для этой информации, но не все классы реализуют IDisposeable или используют этот флаг в его реализации. Например: .foreach (obj {! Dumpheap -type Oracle.DataAccess.Client.OracleConnection -short}) {.printf "\ n \ n"; .printf "Объект в:% p \ nDisposed:% d", $ {obj}, poi ($ {obj} + 12a) & 0x00FF; }
Я не верю, что вы можете запустить сборщик мусора из WinDbg.
Вот несколько полезных инструментов, на которые я привык полагаться для отслеживания выделения памяти:
- SOSEX - дальнейшее расширение для WinDbg в дополнение к SOS, добавляет! dumpgen для дампа объектов из конкретное поколение (отлично подходит для выясняя, что находится на LOH и в Gen 2) и команду! refs что даст родительские ссылки для объект.
- .Net Память Профайлер - это очень полезный инструмент при беге интерактивно, но он также содержит возможность загрузки из файла дампа. Это дает достаточно интуитивно понятный способ отслеживания использования памяти. Легко стоит 250 долларов США, но у них также есть 14-дневная оценка.
WinDBG - это прежде всего отладчик Win32 / Kernel. Так что вы можете попробовать один из управляемых отладчиков, например mDBG. Но я имел обыкновение поддерживать отладку .NET для MSFT, и мне никогда не требовалось ничего подобного для устранения утечек памяти.
Конечно, в первую очередь отладчик Win32 / Kernel?
«Мне никогда не требовалось ничего подобного для устранения утечек памяти» Итак, какой сделал вы используете?
Привет, Роджер, надеюсь, ваша утечка памяти к настоящему времени устранена. :-)
Сначала я был бы уверен, что это «управляемая утечка памяти». Под этим я подразумеваю, что, когда вы смотрите на счетчики монитора производительности, Память .NET CLR -> # байтов во всех кучах увеличивается с той же скоростью, что и счетчик Процесс -> Частные байты для того же процесса. Если это так, то вы можете использовать описанные выше приемы.
Если это не так, у вас может быть собственная утечка, которая является результатом выполнения управляемого кода. Чаще всего я вижу, что сборки .NET загружаются в процессе, а не выгружаются. Это похоже на утечку собственной памяти в Perfmon.
Я бы посоветовал вам попробовать запустить правило утечки в DebugDiag и посмотреть, что в отчете о памяти отображается как утечка стека вызовов.
Вот еще один отличный ресурс по этой теме: У меня утечка памяти !!! Что я делаю? (определяя «где»)
Спасибо, Аарон
Это решено. Я использовал методы из других ответов, чтобы выяснить, что «просочилось». Это была загрузка объектов PaintEventArgs или что-то в этом роде. Причина: анимированный индикатор выполнения, который перерисовывался 10 раз в секунду. Так что на самом деле это была не утечка, а просто элемент управления, использующий слишком много памяти.
Я заинтересован. Не могли бы вы объяснить, почему вы не считаете это необходимым?