Фрагментация кучи больших объектов
Приложение 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.
В нашем случае в пути кода десериализации есть общий код, который интернирует идентификаторы сущности во время демаршаллинга: теперь я сильно подозреваю, что это виновник. Тем не менее, намерения разработчика были явно хорошими, поскольку они хотели убедиться, что если одна и та же сущность будет десериализована несколько раз, то только один экземпляр строки идентификатора будет сохранен в памяти.
7 ответов
CLR использует LOH для предварительного выделения нескольких объектов (таких как массив, используемый для интернированных строк). Некоторые из них имеют размер менее 85000 байт и, таким образом, обычно не выделяются на LOH.
Это деталь реализации, но я предполагаю, что причина этого состоит в том, чтобы избежать ненужной сборки мусора экземпляров, которые должны выживать до тех пор, пока сам процесс не выполняется.
Также из-за несколько эзотерической оптимизации, любой double[] 1000 или более элементов также выделяется на LOH.
.NET Framework 4.5.1 имеет возможность явно сжимать кучу больших объектов (LOH) во время сборки мусора.
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();
Смотрите больше информации в GCSettings.LargeObjectHeapCompactionMode
При чтении описаний того, как работает GC, и части о том, как долгоживущие объекты оказываются в поколении 2, и коллекции объектов LOH происходит только при полном сборе - как и при сборе поколения 2, возникает идея, которая приходит на ум.... почему бы просто не сохранить объекты второго поколения и большие объекты в одной куче, так как они собираются вместе?
Если это действительно так, то это объясняет, как маленькие объекты оказываются в том же месте, что и LOH, - если они достаточно долго живут, чтобы оказаться во втором поколении.
И поэтому ваша проблема может показаться довольно хорошим опровержением идеи, которая приходит мне в голову - это приведет к фрагментации LOH.
Резюме: ваша проблема может быть объяснена тем, что LOH и поколение 2 совместно используют одну и ту же область кучи, хотя это ни в коем случае не является доказательством того, что это объяснение.
Обновление: вывод !dumpheap -stat в значительной степени уносит эту теорию из воды! Поколение 2 и LOH имеют свои регионы.
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();
Если формат распознается как ваше приложение, почему вы не определили код, который генерирует этот формат строки? Если есть несколько возможностей, попробуйте добавить уникальные данные, чтобы выяснить, какой путь к коду является виновником.
Тот факт, что массивы чередуются с большими освобожденными объектами, заставляет меня предположить, что они изначально были парными или, по крайней мере, связаны между собой. Попробуйте определить освобожденные объекты, чтобы выяснить, что их генерировало, и связанные строки.
Как только вы определите, что генерирует эти строки, попробуйте выяснить, что будет препятствовать их GCed. Возможно, они помещены в забытый или неиспользованный список для целей регистрации или чего-то подобного.
РЕДАКТИРОВАТЬ: игнорировать область памяти и конкретный размер массива на данный момент: просто выяснить, что делается с этими строками, чтобы вызвать утечку. Попробуйте!GCRoot, когда ваша программа создала или манипулировала этими строками один или два раза, когда меньше объектов для отслеживания.
Вот несколько способов идентифицировать точный стек вызовов для выделения LOH.
И чтобы избежать фрагментации LOH, предварительно выделите большой массив объектов и закрепите их. Повторно используйте эти объекты при необходимости. Вот пост на фрагментации LOH. Нечто подобное может помочь избежать фрагментации LOH.
Отличный вопрос, я узнал, прочитав вопросы.
Я думаю, что другая часть пути кода десериализации также использует кучу больших объектов, отсюда и фрагментация. Если бы все строки были интернированы в то же самое время, я думаю, вы были бы в порядке.
Учитывая, насколько хорош сборщик мусора.net, достаточно просто дать пути кода десериализации создать нормальный строковый объект. Не делайте ничего более сложного, пока необходимость не будет доказана.
В большинстве случаев я хотел бы сохранить хэш-таблицу последних нескольких строк, которые вы видели, и использовать их повторно. Ограничивая размер хеш-таблицы и передавая размер при создании таблицы, вы можете остановить большую часть фрагментации. Затем вам нужен способ удалить строки, которые вы недавно не видели, из хеш-таблицы, чтобы ограничить его размер. Но если строки, создаваемые путем кода десериализации, недолговечны, в любом случае, вы ничего не выиграете.