Огромная куча с очень небольшим количеством файлов дампа Windows - PullRequest
0 голосов
/ 17 мая 2018

У нас есть приложение, которое работает более 5 месяцев, и теперь оно использует 3,5 ГБ памяти.Мы также заметили, что использование памяти медленно увеличивается день ото дня.Поэтому мы подозреваем, что где-то может быть утечка памяти, и мы использовали инструмент DebugDiag для анализа созданного нами файла дампа.Однако нам трудно понять результаты анализа.

Обновление:

Похоже, проблема в самом DebugDiag.Я сам создал еще один файл дампа, и DebugDig показал, что выделена только одна куча, что явно неправильно.Итак, новый вопрос: я что-то упустил, когда открывал файл .DMP с помощью DebugDig?


Основной вопрос:

Размер кучи равен 3,35 ГБ, но сумма выделенных топ-10до менее чем 20 МБ.Так, где же используется оставшаяся память?


Ниже приводится сводная информация о анализе кучи:

Heap Summary
Number of heaps   14 Heaps 
Total reserved memory   3.36 GBytes 
Total committed memory   3.33 GBytes
------------------------------------
Top 10 heaps by reserved memory

0x00240000                    3.35GBytes
0x00600000                    2.4MBytes
0x01fe0000                    2.4MBytes
......
------------------------------------
Top 10 heaps by committed memory
0x00240000                    3.35GBytes
0x00740000                    1.45MBytes
0x00600000                    1.44MBytes
......

Первая куча - это куча процесса по умолчанию, и ее размер соответствуетнаше наблюдение за использованием памяти приложения.Ниже приведена подробная информация о первой куче:

Heap Details

Heap 1 - 0x00240000

Heap Name   Default process heap 
Heap Description   This heap is created by default and shared by all modules 
                   in the process 
Reserved memory   3.35 GBytes 
Committed memory   3.32 GBytes(99.13% of reserved) 
Uncommitted memory   29.89 MBytes(0.87% of reserved) 
Number of heap segments   217 segments 
Number of uncommitted ranges   227 range(s) 
Size of largest uncommitted range   11.19 MBytes 
Calculated heap fragmentation Unavailable 

Итак, очевидно, что эта куча выделила 217 сегментов, которые составляют до 3,35 ГБ.Однако то, что меня смутило, это выделение кучи, показанное ниже:

Top 10 allocations by size

Allocation Size - 1045632        5.98 MBytes
Allocation Size - 1048560        3 MBytes
Allocation Size - 1024000        1000 KBytes
Allocation Size - 1013248        989.5 KBytes
Allocation Size - 1005440        981.88 KBytes
Allocation Size - 1001216        977.75 KBytes
Allocation Size - 962528         939.97 KBytes
Allocation Size - 961272         938.74 KBytes
Allocation Size - 938088         916.1 KBytes
Allocation Size - 924672         903 KBytes
-------------------------------------

Top 10 allocations by count

Allocation Size - 1045632        6 allocations(s)
Allocation Size - 1048560        3 allocations(s)
Allocation Size - 17152          3 allocations(s)
Allocation Size - 261120         2 allocations(s)
Allocation Size - 48896          1 allocations(s)
Allocation Size - 86784          1 allocations(s)
Allocation Size - 96512          1 allocations(s)
Allocation Size - 98952          1 allocations(s)
Allocation Size - 117248         1 allocations(s)
Allocation Size - 132160         1 allocations(s)

Таким образом, первые 10 выделений составляют менее 20 МБ памяти, но общий размер кучи составляет 3,3 ГБ.Я хотел бы, чтобы, возможно, остальная часть памяти могла уйти?

...