Обнаружение утечек памяти usin PerfView

Я искал утечку памяти в службе Windows, которая используется как служба интеграции.Обнаружение утечек памяти usin PerfView

По запросу «doIntegration()» я вижу, что использование памяти становится выше, чем до вызова, и что оно увеличивается примерно на 0,5 МБ за звонок.

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

метод Устранение:

1) Возьмите кучу снимок перед первым doIntegraion вызова

2) Сядьте кучного снимок после doIntegration вызова

3) Выполните шаг 2 несколько раз

4) Проверьте, какой метод/группа получает больше за звонок

5) Используйте разницу на отдельных моментальных снимках, чтобы найти где e утечка памяти

Я вижу, что LIB mscorlib! RuntypeType - это метод/группа, которая становится выше каждый раз. Когда я пытаюсь проверить, что относится к нему я получаю

возлагали ручки
- .NET Root
  - ROOT

И я не могу для увеличения дерева.

Когда я выбираю вид, RefTree я могу увидеть еще кое-что.

ROOT 100%
- .NET ROOT 100%
  - возлагали Ручки 70,6%
    - LIB mscorlib! RuntimeType 46%
    - LIB mscorlib! Отражение .... 13,4% ...
  - Статический вары 30,7%
    - ns.ConfigurationSettings 59,5%
    - ns.Leaks.ConfigurationSettings -33.3%

Я сделал диф несколько снимков, и единственный способ/группа, которая увеличивает это Закрепленные ручки, и они относятся только к mscorlib типов.

У кого-нибудь еще была такая проблема?

Я думаю, что проблема может заключаться в сериализации из Model to XML с помощью XMLSerializer, но я не уверен.

Кто-нибудь знает другой способ попытаться найти утечку памяти?

Спасибо :)

источник

2015-10-15 Alex

Посмотрите на трассировки стека, где созданы эти объекты, возможно, это подскажет вам, что представляют собой эти объекты. –

Спасибо! Я попытался проследить его, и, как я полагал, это связано с сериализатором. Сериализатор открывается с помощью конструктора, который создает временную сборку, и, по-видимому, эта сборка выходит за пределы юридического лица GCs. Таким образом, каждый раз, когда вызывается деинтеграция, создается несколько temp asemblies. – Alex

Ответ приходит довольно поздно. Но я был прав в своем предположении, что это был сериализатор, который увеличивал использование памяти на «doWork».

XmlSerializer имеет несколько «неприятных» конструкторов, которые фактически создадут временную сборку для каждого init, и они не будут собраны GC.

Я кэшировал разные XmlSerializers, которые использовали один из неприятных конструкторов, чтобы создать временную сборку только один раз.

Теперь нет утечек памяти слева.

источник

2015-11-24 09:11:52 Alex

Обнаружение утечек памяти usin PerfView

ответ

Смежные вопросы