. net неуправляемая утечка памяти - PullRequest
Новая
       77

. net неуправляемая утечка памяти

0 голосов
/ 31 марта 2020

У меня есть windows служба для получения электронной почты, которая использует OpenPop. Однако использование памяти увеличивается до 8G примерно через 3 дня после перезапуска. Оперативный персонал дает мне файл дампа, поэтому я использую windbg для его анализа.

Когда я запускаю !address -summary, я получил: 

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    468      7fd`942f6000 (   7.991 TB)           99.88%
Heap                                    645        1`c3f95000 (   7.062 GB)  72.92%    0.09%
<unknown>                              1347        0`9305f000 (   2.297 GB)  23.72%    0.03%
Image                                  1985        0`0d28d000 ( 210.551 MB)   2.12%    0.00%
Stack                                   366        0`077c0000 ( 119.750 MB)   1.21%    0.00%
Other                                    11        0`001c4000 (   1.766 MB)   0.02%    0.00%
TEB                                     122        0`000f4000 ( 976.000 kB)   0.01%    0.00%
PEB                                       1        0`00001000 (   4.000 kB)   0.00%    0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE                            1725        2`5b3b9000 (   9.426 GB)  97.33%    0.12%
MEM_IMAGE                              2692        0`0f249000 ( 242.285 MB)   2.44%    0.00%
MEM_MAPPED                               60        0`016f8000 (  22.969 MB)   0.23%    0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                468      7fd`942f6000 (   7.991 TB)           99.88%
MEM_COMMIT                             3373        2`10e49000 (   8.264 GB)  85.33%    0.10%
MEM_RESERVE                            1104        0`5aeb1000 (   1.421 GB)  14.67%    0.02%

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE                         1528        2`0092c000 (   8.009 GB)  82.70%    0.10%
PAGE_EXECUTE_READ                       308        0`0b666000 ( 182.398 MB)   1.84%    0.00%
PAGE_READONLY                           924        0`0323a000 (  50.227 MB)   0.51%    0.00%
PAGE_WRITECOPY                          321        0`012f3000 (  18.949 MB)   0.19%    0.00%
PAGE_EXECUTE_READWRITE                  112        0`005d2000 (   5.820 MB)   0.06%    0.00%
PAGE_READWRITE|PAGE_GUARD               122        0`0023c000 (   2.234 MB)   0.02%    0.00%
PAGE_EXECUTE_WRITECOPY                   57        0`00178000 (   1.469 MB)   0.01%    0.00%
PAGE_EXECUTE                              1        0`00004000 (  16.000 kB)   0.00%    0.00%

--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free                                      5`2d890000      7f9`6d640000 (   7.974 TB)
Heap                                      0`25d40000        0`00fd0000 (  15.813 MB)
<unknown>                                 0`32e89000        0`0eb07000 ( 235.027 MB)
Image                                   7fe`f466a000        0`01338000 (  19.219 MB)
Stack                                     0`19c60000        0`000fc000 (1008.000 kB)
Other                                     0`00de0000        0`00181000 (   1.504 MB)
TEB                                     7ff`ffdb8000        0`00002000 (   8.000 kB)
PEB                                     7ff`fffdf000        0`00001000 (   4.000 kB)

и !eeheap -gc Я получил: 

Number of GC Heaps: 1
generation 0 starts at 0x000000051da29040
generation 1 starts at 0x000000051d891000
generation 2 starts at 0x0000000001281000
ephemeral segment allocation context: none
 segment     begin allocated  size
0000000001280000  0000000001281000  000000000b1eae80  0x9f69e80(167157376)
0000000031990000  0000000031991000  0000000032e68ee0  0x14d7ee0(21855968)
000000007fff0000  000000007fff1000  0000000081a99330  0x1aa8330(27951920)
000000008fff0000  000000008fff1000  0000000099d1bb00  0x9d2ab00(164801280)
000000009fff0000  000000009fff1000  00000000a77989c0  0x77a79c0(125467072)
000000051d890000  000000051d891000  000000052352fe40  0x5c9ee40(97119808)
Large object heap starts at 0x0000000011281000
 segment     begin allocated  size
0000000011280000  0000000011281000  0000000019236c28  0x7fb5c28(133913640)
0000000048fa0000  0000000048fa1000  0000000050a87908  0x7ae6908(128870664)
0000000050fa0000  0000000050fa1000  000000005387c418  0x28db418(42841112)
00000000afff0000  00000000afff1000  00000000b3bf0840  0x3bff840(62912576)
Total Size:              Size: 0x39fd2518 (972891416) bytes.
------------------------------
GC Heap Size:            Size: 0x39fd2518 (972891416) bytes.

Из этих двух команд имеется некоторая неуправляемая память протечь. Как узнать, что находится в неуправляемой памяти и каким способом?

Ответы [ 2 ]

1 голос
/ 31 марта 2020

Пока нет доказательств того, что ваша ситуация является утечкой памяти. Да у вас 8 ГБ в родных кучах. Но у вас также есть 900 МБ в управляемых кучах, которые могут содержать живые объекты.

Я предлагаю использовать и начинать с !dumpheap -stat, если вы действительно хотите go с WinDbg. В противном случае используйте профилировщик памяти. NET. Многие люди имеют лицензию JetBrains dotMemory, потому что они используют R # Ultimate. Его гораздо проще использовать, чем WinDbg, и он лучше поддерживает сравнение снимков во времени.

0 голосов
/ 31 марта 2020

Насколько я вижу, нет разбивки на использование памяти отдельных. net компонентов. Для этого вам нужно загрузить расширение SOS отладчика . Статья Охота. NET утечки памяти с помощью Windbg. Автор André Snede Kock предоставляет некоторые дополнительные сведения.

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

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

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

...