Кто использует мою память: много виртуальных распределений, но небольшие кучи - PullRequest
1 голос
/ 18 января 2012

В моем приложении WPF .net, похоже, происходит утечка памяти (я также использую нативные и сторонние компоненты).Я взял несколько дампов памяти и проанализировал их с помощью DebugDiag, WinDBG и VMMap.Я видел, что управляемая куча, а также собственные кучи и потоки довольно стабильны (на низком уровне).Затем я сделал анализ с DebugDiag.Это показывает, что большая часть выделена «Виртуальным выделением» (2,5 ГБ: 1,2 ГБ зафиксировано и 1,2 ГБ зарезервировано).

VMMap показывает, что большая часть моей памяти либо «Личные данные», либоодна свалка даже "Таблица страниц" ... Как я могу выяснить, кто за это отвечает ???(Я бы ожидал, что управляемая или собственная куча будет расти)

Изменить (позвольте мне добавить несколько дополнительных счетчиков):

.NET CLR Memory | # Total committed Bytes        357945K  
.NET CLR Memory | # Total reserved Bytes         402554K  
.NET CLR Memory | Large Object Heap size          79182K  
Process | Private Bytes                         1299080K  
Process | Virtual Bytes                         2876524K


-------------------- Usage SUMMARY --------------------------
    TotSize (      KB)   Pct(Tots) Pct(Busy)   Usage
   92d50000 ( 2405696) : 57.36%    83.79%    : RegionUsageIsVAD
   50c11000 ( 1323076) : 31.55%    00.00%    : RegionUsageFree
   12c6c000 (  307632) : 07.33%    10.71%    : RegionUsageImage
    79fe000 (  124920) : 02.98%    04.35%    : RegionUsageStack
          0 (       0) : 00.00%    00.00%    : RegionUsageTeb
     540000 (    5376) : 00.13%    00.19%    : RegionUsageHeap
    1ae5000 (   27540) : 00.66%    00.96%    : RegionUsagePageHeap
          0 (       0) : 00.00%    00.00%    : RegionUsagePeb
          0 (       0) : 00.00%    00.00%    : RegionUsageProcessParametrs
          0 (       0) : 00.00%    00.00%    : RegionUsageEnvironmentBlock

Ответы [ 2 ]

1 голос
/ 18 января 2012

Несколько баллов ...

В вашем приложении есть как собственный, так и управляемый код, поэтому постарайтесь выяснить, какая половина является проблемным ребенком.Запустите perfmon с управляемыми и собственными счетчиками памяти, чтобы увидеть, в чем проблема.Если как управляемые, так и собственные счетчики со временем увеличиваются, то у вас есть потенциальная утечка.Если со временем увеличивается только собственный, то виноват собственный код.

Я всегда использую следующие 5 счетчиков:

  • .NET CLR Memory |# Всего зафиксировано байт
  • .NET CLR Memory |# Всего зарезервированных байтов
  • .NET CLR Memory |Размер кучи больших объектов
  • Процесс |Частные байты
  • Процесс |Виртуальные байты

Также обратите внимание на размер кучи больших объектов.Вы также можете просмотреть содержимое этих куч в WinDbg.Наконец, в то время как объекты в LOH со временем будут собирать мусор, LOH никогда не уплотняется, поэтому LOH со временем подвергается фрагментации, что становится заметным, если вы случайно разместите в LOH слишком часто.

РЕДАКТИРОВАТЬУ меня никогда не было большой удачи с VMMap, вместо этого я в основном использую perfmon и WinDbg, а иногда и DebugDiag.

0 голосов
/ 18 января 2012

Трудно предположить, не взглянув на дампы, приложение или ваш код, однако вы уже смотрели на них: http://msdn.microsoft.com/en-us/magazine/cc163491.aspx

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...