Измерение кучи

Shallow size против retained size — различие, которое важно

Этот урок — компаньон уровня движка к performance/04-gc/06-gc-production (которое покрывает сторону эксплуатации — алерты, лимиты, рестарты). Здесь — как читать кучу напрямую.

Heap snapshot — это полный дамп графа объектов в один миг: каждый объект, его размер и его ссылки. Два числа размера на объект, и путаница между ними тратит часы:

• Shallow size — память, которую объект занимает сам (его собственные поля), исключая то, на что он ссылается. У массива shallow size крошечный, даже если он держит миллионы огромных объектов.
• Retained size — память, которая освободилась бы при удалении этого объекта, то есть объект плюс всё достижимое только через него. Это число говорит вам стоимость утечки: маленький объект с огромным retained size якорит большое поддерево.

Утечки ищут по retained size, а не shallow size. У утёкшего Map тривиальный shallow size, но retained size — каждая запись, которую он один держит живой.

Dominator tree

Чтобы вычислить retained size, V8 строит dominator tree графа объектов. Объект A доминирует объект B, если каждый путь от корня к B проходит через A — то есть, если A освобождён, B неизбежно тоже становится недостижимым. Retained size объекта — это суммарный shallow size всего, что он доминирует.

Dominator tree — карта охотника за утечками: идите вниз от корней и найдите объект, чей retained size велик и неожидан. Его доминируемое поддерево — ровно то, что он держит живым, а путь от корня к нему — это retainer path, который надо оборвать.

Техника трёх снимков

Один снимок показывает, что в куче, но не что растёт. Классический метод поиска утечек — три снимка:

1. Снимок 1 — задать базовую линию после разогрева.
2. Погонять подозреваемую операцию N раз (навигация, запрос и т.д.).
3. Снимок 2.
4. Погонять её ещё N раз.
5. Снимок 3.

Сравнение DevTools «Objects allocated between snapshots» показывает объекты, рождённые после снимка 1 и всё ещё живые в снимке 3. В здоровой операции их должно быть около нуля (всё недолговечное собрано); утечка показывает число, растущее линейно с N. Отсортируйте выживших по retained size, откройте одного и прочитайте его retainer path до корня. Эта последовательность — diff, сортировка по retained, чтение retainer — и есть весь процесс.

Allocation timeline и sampling

Снимки — это точка во времени; allocation timeline (DevTools) и allocation sampling отвечают «откуда текучка?», относя аллокации к стекам вызовов, которые их сделали, во времени. Sampling достаточно низкооверхедный для около-продакшен использования. Так находят горячее место аллокации, гонящее давление GC (проблема minor-GC из урока 02), отличную от утечки удержания.

Счётчики Node и программные

DevTools не всегда подключён. Числа, которые можно логировать:

• process.memoryUsage() → { rss, heapTotal, heapUsed, external, arrayBuffers }. heapUsed = живые объекты кучи V8; heapTotal = выделенная куча V8; rss = вся резидентная память процесса (включая нативную, стеки, код); external / arrayBuffers = память, удерживаемая C++-объектами, привязанными к JS (Buffer, ArrayBuffer). Растущий heapUsed ⇒ утечка удержания JS; растущий external/arrayBuffers при плоском heapUsed ⇒ утечка Buffer/нативная; высокий rss при плоском heapUsed ⇒ фрагментация.
• v8.getHeapStatistics() / getHeapSpaceStatistics() — размеры по пространствам (new vs old vs large-object), used_heap_size, heap_size_limit. Позволяет следить именно за old space.
• --trace-gc / --trace-gc-verbose — логировать каждое событие GC с heap-before/heap-after и временем паузы. Постройте old-space-after во времени: монотонный рост = утечка; колебание вокруг среднего = GC справляется.
• --max-old-space-size=<MB> — потолок old space; его поднятие покупает запас, но не чинит утечку (лишь оттягивает OOM и удлиняет паузы major GC). По умолчанию это примерно 2 ГБ на современном 64-битном Node, но зависит от версии — измеряйте, не предполагайте.
• v8.writeHeapSnapshot() — выгрузить .heapsnapshot изнутри процесса (например, по сигналу), чтобы загрузить в DevTools офлайн. Бесценно в продакшене, где нельзя подключить отладчик.

В браузере performance.measureUserAgentSpecificMemory() даёт cross-origin-isolated оценку памяти страницы с разбивкой по типам — поддерживаемого преемника старого нестандартного performance.memory.