[C#] Фрагментация больших объектов


Answers

.NET Framework 4.5.1 имеет возможность явно уплотнять кучу больших объектов (LOH) во время сбора мусора.

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();

Подробнее о GCSettings.LargeObjectHeapCompactionMode

Question

Приложение C # /. NET, над которым я работаю, страдает медленной утечкой памяти. Я использовал CDB с SOS, чтобы попытаться определить, что происходит, но данные, похоже, не имеют никакого смысла, поэтому я надеялся, что один из вас, возможно, испытал это раньше.

Приложение работает в 64-битной структуре. Он непрерывно вычисляет и сериализует данные на удаленный хост и наносит большой кусок большого объекта (LOH). Тем не менее, большинство объектов LOH, которые я ожидаю, будут временными: после завершения вычисления и отправки на удаленный хост, память должна быть освобождена. Однако я вижу большое количество (живых) массивов объектов, чередующихся со свободными блоками памяти, например, с использованием случайного сегмента из LOH:

0:000> !DumpHeap 000000005b5b1000  000000006351da10
         Address               MT     Size
...
000000005d4f92e0 0000064280c7c970 16147872
000000005e45f880 00000000001661d0  1901752 Free
000000005e62fd38 00000642788d8ba8     1056       <--
000000005e630158 00000000001661d0  5988848 Free
000000005ebe6348 00000642788d8ba8     1056
000000005ebe6768 00000000001661d0  6481336 Free
000000005f214d20 00000642788d8ba8     1056
000000005f215140 00000000001661d0  7346016 Free
000000005f9168a0 00000642788d8ba8     1056
000000005f916cc0 00000000001661d0  7611648 Free
00000000600591c0 00000642788d8ba8     1056
00000000600595e0 00000000001661d0   264808 Free
...

Очевидно, я ожидаю, что это будет так, если бы мое приложение создавало долгоживущие большие объекты во время каждого расчета. (Он делает это, и я согласен, что будет степень фрагментации LOH, но это не проблема.) Проблема заключается в очень маленьких (1056 байт) объектных массивах, которые вы можете увидеть в приведенном выше дампе, который я не вижу в коде создаются и которые каким-то образом укоренены.

Также обратите внимание на то, что CDB не сообщает тип, когда кусок сегмента сбрасывается: я не уверен, связано это или нет. Если я сброшу отмеченный (<-) объект, CDB / SOS сообщает об этом в порядке:

0:015> !DumpObj 000000005e62fd38
Name: System.Object[]
MethodTable: 00000642788d8ba8
EEClass: 00000642789d7660
Size: 1056(0x420) bytes
Array: Rank 1, Number of elements 128, Type CLASS
Element Type: System.Object
Fields:
None

Элементы массива объектов - это все строки, и строки распознаются как из нашего кода приложения.

Кроме того, я не могу найти их корни GC, поскольку команда GCRoot зависает и никогда не возвращается (я даже пытался оставить ее на ночь).

Поэтому я был бы очень признателен, если бы кто-нибудь мог пролить свет на то, почему эти маленькие (<85k) объектные массивы заканчиваются на LOH: в каких ситуациях .NET помещает небольшой массив объектов? Кроме того, знает ли кто-нибудь об альтернативном способе определения корней этих объектов?

Обновление 1

Еще одна теория, которую я придумал поздно вчера, состоит в том, что эти массивы объектов начались большими, но были сокращены, оставляя блоки свободной памяти, которые очевидны в свалках памяти. Что вызывает у меня подозрение, так это то, что массивы объектов всегда кажутся 1056 байтами (128 элементов), 128 * 8 для ссылок и 32 байтами служебных данных.

Идея состоит в том, что, возможно, какой-то небезопасный код в библиотеке или в CLR искажает количество полей элементов в заголовке массива. Я знаю длинный выстрел ...

Обновление 2

Благодаря Брайану Расмуссену (см. Принятый ответ) проблема была идентифицирована как фрагментация LOH, вызванная табличной статической таблицей! Я написал приложение для быстрого тестирования, чтобы подтвердить это:

static void Main()
{
    const int ITERATIONS = 100000;

    for (int index = 0; index < ITERATIONS; ++index)
    {
        string str = "NonInterned" + index;
        Console.Out.WriteLine(str);
    }

    Console.Out.WriteLine("Continue.");
    Console.In.ReadLine();

    for (int index = 0; index < ITERATIONS; ++index)
    {
        string str = string.Intern("Interned" + index);
        Console.Out.WriteLine(str);
    }

    Console.Out.WriteLine("Continue?");
    Console.In.ReadLine();
}

Приложение сначала создает и разыгрывает уникальные строки в цикле. Это просто, чтобы доказать, что память не протекает в этом сценарии. Очевидно, это не должно быть, и это не так.

Во втором цикле создаются и интернируются уникальные строки. Это действие заставляет их встречаться в стажерской таблице. То, что я не понимал, - это то, как представлен стажер-стол. По-видимому, он состоит из набора страниц - массивов объектов из 128 строковых элементов, которые создаются в LOH. Это более очевидно в CDB / SOS:

0:000> .loadby sos mscorwks
0:000> !EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00f7a9b0
generation 1 starts at 0x00e79c3c
generation 2 starts at 0x00b21000
ephemeral segment allocation context: none
 segment    begin allocated     size
00b20000 00b21000  010029bc 0x004e19bc(5118396)
Large object heap starts at 0x01b21000
 segment    begin allocated     size
01b20000 01b21000  01b8ade0 0x00069de0(433632)
Total Size  0x54b79c(5552028)
------------------------------
GC Heap Size  0x54b79c(5552028)

Взятие отвала сегмента LOH показывает образец, который я видел в протекающем приложении:

0:000> !DumpHeap 01b21000 01b8ade0
...
01b8a120 793040bc      528
01b8a330 00175e88       16 Free
01b8a340 793040bc      528
01b8a550 00175e88       16 Free
01b8a560 793040bc      528
01b8a770 00175e88       16 Free
01b8a780 793040bc      528
01b8a990 00175e88       16 Free
01b8a9a0 793040bc      528
01b8abb0 00175e88       16 Free
01b8abc0 793040bc      528
01b8add0 00175e88       16 Free    total 1568 objects
Statistics:
      MT    Count    TotalSize Class Name
00175e88      784        12544      Free
793040bc      784       421088 System.Object[]
Total 1568 objects

Обратите внимание, что размер массива объекта составляет 528 (а не 1056), потому что моя рабочая станция 32 бит, а сервер приложений - 64 бит. Массивы объектов по-прежнему составляют 128 элементов.

Таким образом, мораль к этой истории - быть очень осторожным интернированием. Если строка, в которой вы выполняете интернирование, как известно, не является членом конечного набора, ваше приложение будет течь из-за фрагментации LOH, по крайней мере, в версии 2 CLR.

В нашем приложении есть общий код в коде кода десериализации, который ставит под идентификаторы объекта во время разборки: я теперь сильно подозреваю, что это преступник. Однако намерения разработчика были явно хорошими, поскольку они хотели удостовериться, что если один и тот же объект десериализуется несколько раз, то в памяти будет сохранен только один экземпляр строки идентификатора.




Если формат распознается как ваше приложение, почему вы не определили код, который генерирует этот строковый формат? Если есть несколько возможностей, попробуйте добавить уникальные данные, чтобы выяснить, какой путь кода является виновником.

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

Как только вы определите, что генерирует эти строки, попробуйте выяснить, что будет препятствовать их GCed. Возможно, они заполняются в забытом или неиспользуемом списке для целей ведения журнала или чего-то подобного.

EDIT: Игнорируйте область памяти и размер конкретного массива на данный момент: просто выясните, что делается с этими строками, чтобы вызвать утечку. Попробуйте GCRoot, когда ваша программа создала или манипулировала этими строками только один или два раза, когда трассировка объектов меньше.




Вот несколько способов определить точный call-stack распределения LOH .

И чтобы избежать фрагментации LOH. Предварительно выделите большой массив объектов и скопируйте их. Повторно используйте эти объекты, когда это необходимо. Вот post на LOH Fragmentation. Что-то вроде этого могло бы помочь избежать фрагментации LOH.