8 lines
19 KiB
JSON
8 lines
19 KiB
JSON
{
|
||
"index": 366,
|
||
"slug": "dconf-2017-под-капотом-мусорщика-ди-дмитрий-ол",
|
||
"title": "Сборщик мусора D под нагрузкой: от паузы к устройству пулов",
|
||
"excerpt": "Пауза в D-приложении не доказывает, что виноват только GC. Разбираем пулы малых и больших объектов, консервативную маркировку и порядок проверки перед изменением режима сборки.",
|
||
"contentHtml": "<p>Представим вечерний batch в D-сервисе: оператор заметил симптом: редкая длинная пауза, RSS растёт, а разработчик сначала хочет отключить сборщик мусора. Цена такого шага понятна: пока GC выключен, временные данные продолжают занимать память, и процесс может упереться в лимит. Но ручное освобождение тоже не лечит паузу, если её вызвали аллокатор, жизненный цикл ссылок или профиль нагрузки.</p>\n<p>Сначала зафиксируйте, что именно произошло: время обработки, размер входа, число аллокаций и длительность остановки. Затем отделите работу приложения от работы GC и только после этого меняйте код или режим сборки. Исторический разбор Дмитрия Ольшанского помогает понять, почему одной строки «GC медленный» недостаточно: стоимость возникает в пулах, таблицах, маркировке и восстановлении списков свободных блоков.</p>\n<h2>Сценарий: пауза в batch</h2>\n<p>В этом сценарии команда получает один симптом — задержка появилась после нескольких проходов по данным. Сначала она смотрит на среднее время batch и не находит проблемы. Затем разработчик сравнивает максимальную паузу GC с размером кучи и видит, что среднее скрывает редкие остановки. После этого команда проверяет, сколько объектов переживает сборку, и возвращается к исходной гипотезе: виноват не обязательно сам GC, а способ выделения и удержания памяти.</p>\n<p>Сценарий учебный: это не отчёт о production-замере. Его результатом должна быть запись «какую фазу и какой показатель мы проверили», а не обещание ускорения. Для исторических деталей ниже используется разбор состояния runtime в 2017 году; для API — актуальная документация D, поэтому границы между ними отмечены отдельно.</p>\n<h2>Что описывает исторический разбор</h2>\n<p>В записи от 15 июня 2017 года автор описывает GC как набор пулов. Пул объединяет отображённую память и метаданные: таблицы битов отметки и освобождения, списки свободных блоков и сведения о расположении объектов. Если один пул не обслуживает запрос, runtime создаёт новый. Это описание объясняет архитектуру, но не заменяет проверку исходников конкретной версии druntime.</p>\n<p>Исторический runtime разделял малые и большие объекты. Для малых выделений автор указывает верхнюю границу 2 КБ и классы размеров 16, 32, 64, 128, 256, 512, 1024 и 2048 байт. Запрос округляется к классу, после чего проверяется глобальный список свободных блоков. Если подходящего блока нет, пул выделяет страницу и добавляет её в список объектов этого класса.</p>\n<figure><img src=\"/assets/illustrations/gc-small-pools.svg\" alt=\"Схема пулов малых объектов в историческом GC D\" /><figcaption>Учебная схема: размер страницы связывается с классом малых объектов через таблицу страниц.</figcaption></figure>\n<p>Класс назначается странице, а не каждому объекту отдельно. Поэтому внутренний указатель сначала сопоставляется со страницей, затем с классом размера, и только потом по маске вычисляется начало объекта. В статье 2017 года это названо источником дополнительных обращений к таблице страниц и метаданным. Вывод ограничен: речь идёт о конструкции, разобранной автором в тот момент, а не о гарантии для любого современного GC.</p>\n<p>Степени двойки упрощают вычисление маски, но дают внутреннюю фрагментацию: запрос, чуть превышающий нижний класс, получает следующий блок. Верхняя оценка до 50% относится к такому правилу округления, а не к каждому распределению. Фактический перерасход зависит от распределения размеров, поэтому его нельзя выводить из одного значения RSS.</p>\n<h2>Большие объекты и путь указателя</h2>\n<p>Для больших объектов исторический разбор указывает гранулярность страницы 4 КБ и отдельную таблицу, которая помогает восстановить начало объекта по адресу внутри диапазона. При выделении свободный список страниц просматривается линейно. Для объекта на 100 МБ и больше метаданные могут стать заметными относительно полезных данных, особенно если изменение размера не удаётся выполнить на месте.</p>\n<p>В маркировке возможный указатель проходит несколько проверок. Сначала runtime проверяет диапазон кучи, затем ищет подходящий пул. После этого таблица страниц сообщает, является ли адрес малым объектом, началом большого объекта, продолжением диапазона или свободной памятью. Только затем вычисляется начало блока и проверяется бит отметки.</p>\n<p>Так появляется оценка N × log(P): N — число проверяемых значений, P — число пулов, а log(P) — стоимость бинарного поиска пула в описанной архитектуре. Это модель пути, а не бенчмарк. Она подсказывает, что профилировать нужно не только внешний вызов сборки, но и количество сканируемых областей, пулов и кандидатов.</p>\n<h2>Почему у сборки несколько фаз</h2>\n<p>В историческом описании цикл состоит из подготовки, маркировки, очистки и возврата памяти. На подготовке runtime подготавливает сведения о свободных областях. Если для этого нужно пройти по спискам свободных блоков, работа попадает в критический участок паузы. На маркировке консервативный GC сохраняет значение, похожее на указатель, когда не может доказать обратное.</p>\n<p>Ложный указатель не доказывает утечку: он лишь может удержать объект до следующего цикла. Точно так же рост heap после сборки не доказывает дефект GC — объект может оставаться достижимым через кэш или долгожившую структуру. Поэтому проверка должна сопоставлять живые ссылки, профили аллокаций и фазу, в которой выросла задержка.</p>\n<p>На очистке вызываются финализаторы, если они предусмотрены, и отмечаются свободные блоки. На возврате памяти восстанавливаются списки свободных блоков; исторический разбор отдельно указывает на повторный проход по малым пулам. Это объясняет, почему одинаковая по длительности пауза может зависеть не только от числа недостижимых объектов, но и от числа страниц и элементов метаданных.</p>\n<p>Актуальная документация D формулирует более устойчивый контракт: GC консервативно маркирует достижимую память, а <code>GC.collect</code> может приостановить потоки на части цикла. Точные фазы, пороги и структуры зависят от реализации. Если нужен ответ для конкретной версии компилятора, сначала закрепите версию и прочитайте её druntime, а затем подтвердите вывод профилем.</p>\n<h2>Воспроизводимый пример измерения</h2>\n<p>Ниже приведён минимальный пример для локального сравнения двух вариантов. <code>usedSize</code> — размер занятой памяти GC-heap, который может обновляться после сборки. <code>allocatedInCurrentThread</code> — накопительный счётчик байтов, выделенных текущим потоком. Поэтому пример показывает два разных показателя и не выдаёт ни один из них за длительность паузы.</p>\n<pre><code>import core.memory : GC;\nimport std.stdio : writeln;\n\nvoid processBatch(const int[] values) {\n auto before = GC.stats();\n\n foreach (value; values) {\n auto squared = value * value;\n writeln(squared);\n }\n\n auto after = GC.stats();\n writeln(\"heap used delta: \",\n cast(long) after.usedSize - cast(long) before.usedSize);\n writeln(\"thread allocations delta: \",\n after.allocatedInCurrentThread - before.allocatedInCurrentThread);\n}\n\n// Сравнивайте варианты на одном входе и в одном режиме сборки.</code></pre>\n<p>В цикле нет искусственного выделения памяти, поэтому фрагмент не является нагрузочным тестом GC. Его задача — показать границу измерения. Для реального сравнения сохраните входной набор, версию компилятора, режим сборки, число повторов и профиль пауз. Если нужно проверить именно остановки, используйте доступные профили runtime, а не делайте вывод по разнице <code>usedSize</code>.</p>\n<h2>Матрица диагностики</h2>\n<table><thead><tr><th>Симптом</th><th>Гипотеза</th><th>Проверка</th><th>Ограниченное действие</th></tr></thead><tbody><tr><td>Редкая длинная пауза</td><td>Маркировка или проход по метаданным</td><td>Сопоставить фазу GC, размер кучи и максимум паузы</td><td>Сначала найти горячую фазу, не отключать GC по одному событию</td></tr><tr><td>Heap растёт после сборки</td><td>Живые ссылки, кэш или ложные указатели</td><td>Сравнить удерживаемые объекты и граф ссылок</td><td>Ограничить кэш, убрать ненужную ссылку и повторить замер</td></tr><tr><td>Частые сборки</td><td>Много короткоживущих объектов</td><td>Посчитать аллокации в цикле и размеры классов</td><td>Переиспользовать буфер и убрать промежуточные значения</td></tr><tr><td>Рост RSS после крупного блока</td><td>Фрагментация или стоимость метаданных</td><td>Сравнить размер блока, резерв и возврат страниц</td><td>Проверить модель больших буферов, не переносить вывод на малые объекты</td></tr><tr><td>Пауза после batch</td><td>Сборка совпала с границей аллокации</td><td>Сравнить распределение задержек с явным сбором на границе</td><td>Оставить <code>GC.collect</code> только при повторяемом улучшении</td></tr></tbody></table>\n<h2>Порядок проверки</h2>\n<ol><li>Зафиксируйте симптом: задержку, частоту, размер входа, RSS и допустимый порог.</li><li>Запустите release-бинарник на повторяемом наборе. Debug-результат не переносите на production без отдельной проверки.</li><li>Отделите время обработки, аллокаций и сборки. Сохраните показатели до и после batch.</li><li>Найдите горячие места, где создаются строки, массивы, замыкания и промежуточные структуры.</li><li>Проверьте удерживаемые ссылки. Рост heap после сборки означает наличие живых данных или ложных указателей, но не доказывает неисправность GC.</li><li>После этого измените только один фактор: структуру данных, размер batch или режим сборки.</li><li>Сравните медиану, хвост задержек и RSS. Среднее значение не заменяет p95 или p99, если проблема редкая.</li><li>Только после повторяемого улучшения проверяйте <code>GC.collect</code> на границе операции. Для <code>GC.disable</code> задайте короткий участок, условие возврата и лимит накопления временных данных.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>Исторический разбор полезен как карта решений GC 2017 года, но не как обещание поведения современного runtime. Порог 2 КБ, классы размеров, гранулярность страницы и четыре фазы нужно перепроверять для версии, на которой работает ваш сервис. Документация <code>core.memory</code> подтверждает публичные счётчики и управление, но не превращает учебный пример в production-бенчмарк.</p>\n<p>Диагностика готова, если записаны версия компилятора, фаза GC, размер кучи, число аллокаций, повторяемый вход и выбранный порог; изменение улучшает хвост задержек на release-профиле; RSS не выходит за лимит; а ручное управление имеет понятное условие возврата. Если этих данных нет, вывод «виноват сборщик» остаётся гипотезой.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://olshansky.me/posts/2017-06-15-inside-d-gc/\">Dmitry Olshansky: Inside D GC</a> — авторский исторический разбор устройства GC и его проблем в 2017 году.</li><li><a href=\"https://dlang.org/spec/garbage.html\">D Language Specification: Garbage Collection</a> — нормативная модель автоматической памяти, консервативной маркировки и ограничений.</li><li><a href=\"https://dlang.org/library/core/memory.html\">D standard library: core.memory</a> — публичный API <code>GC.stats</code>, профилирования и управления сборкой.</li><li><a href=\"https://github.com/dlang/dmd/blob/master/druntime/src/core/memory.d\">DMD druntime: core/memory.d</a> — исходный контракт текущего runtime; конкретную версию следует закреплять отдельно.</li></ul>\n"
|
||
}
|