Профили CPU и охота на утечки по heap-снимкам

Профилирование CPU: найди широкий кадр

Когда сервис тормозит или жрёт ядро, ты не гадаешь — ты сэмплируешь. CPU-профиль записывает, какая функция на стеке в каждый интервал сэмплирования, так что функция, появляющаяся чаще всех, и есть место, куда реально уходит время. Самый быстрый путь в Node — встроенный флаг --cpu-prof: он пишет файл .cpuprofile при выходе, который открывается во вкладке Performance Chrome DevTools. Там ты читаешь flame-граф, где каждый прямоугольник — кадр стека, а ширина = self time — самые широкие кадры и есть твой горячий путь, точка. Глубина — это лишь вложенность вызовов; игнорируй её и гонись за шириной.

# пишет isolate-*.cpuprofile при чистом выходе; открой в Chrome DevTools → Performance
node --cpu-prof --cpu-prof-dir=./prof server.js

# классический tick-процессор V8: текстовый отчёт, без GUI
node --prof server.js
node --prof-process isolate-*.log > processed.txt

--prof плюс node --prof-process дают те же сэмплированные данные в виде текстового tick-отчёта — удобно на headless-машине, где DevTools не открыть. Инструменты выше оборачивают это: 0x генерит интерактивный flame-граф одной командой, а clinic flame делает то же с проводящим тебя сценарием. Все они — сэмплирующие профайлеры (снимают стек каждые N микросекунд, дёшево, ~1–2% накладных) в отличие от инструментирования (оборачивают каждый вызов, точные счётчики, но настолько тяжёлые, что искажают сами тайминги, которые ты меришь). Для боевой диагностики почти всегда нужно сэмплирование. Классическая находка: regex или глубокий JSON.parse всплывает одним жирным кадром, съедающим 40% self time, — оптимизируй его, закэшируй или вынеси с главного потока в Worker.

Heap-снимки: охота на утечку тремя снимками

CPU-профиль утечку не найдёт; для этого ты фотографируешь кучу. Heap-снимок — это полный граф каждого живого объекта и того, кто на кого указывает. Сделай один через v8.writeHeapSnapshot() изнутри процесса, сними по требованию через --heapsnapshot-signal=SIGUSR2 (затем kill -USR2 <pid>) или возьми из вкладки Memory в DevTools. Один снимок говорит, что большое сейчас; он не скажет, что течёт. Для этого ты применяешь технику трёх снимков.

import v8 from "node:v8";

// снимок 1 — базовый, после прогрева
v8.writeHeapSnapshot("./snap-1.heapsnapshot");
await exerciseSuspectPath({ times: 5000 }); // долби подозрительный маршрут
// снимок 2 — после нагрузки
v8.writeHeapSnapshot("./snap-2.heapsnapshot");
await exerciseSuspectPath({ times: 5000 }); // сделай ещё раз
v8.writeHeapSnapshot("./snap-3.heapsnapshot");

Загрузи все три во вкладку Memory, переключи дропдаун на Comparison и используй «Objects allocated between snapshots»: всё, чей счётчик только растёт от снимка 1 → 2 → 3 и никогда не падает после GC, — это твоя утечка. Стабильная нагрузка должна выходить на «пилу» — выделить, собрать, повторить — поэтому ровная восходящая лестница и есть улика. Следующая колонка важнее всего: не shallow size (собственные байты объекта), а retained size — память, которая освободилась бы, если освободить этот объект, то есть всё, что только он держит живым. Сортируй по retained size, выбери конструктор, чей счётчик вырос, и иди по его retainer path (цепочке ссылок, держащих его) прямо к кэшу, массиву или слушателю, который не отпускает.

GC, лимит кучи и что на самом деле значит «утечка»

Прежде чем тянуться к --max-old-space-size, спроси себя: возвращается ли память обратно после полного GC, или пол только растёт? Ответ на этот вопрос разделяет проблему провижена и утечку — а фиксы у них принципиально разные.

Куча V8 поколенческая. Новые выделения попадают в new space, собираемое Scavenge — быстрым, частым, копирующим выживших наружу. Объекты, пережившие пару Scavenge, повышаются в old space, собираемое медленным Mark-Sweep-Compact. Практическое определение утечки выпадает прямо отсюда: old space (и RSS — Resident Set Size, суммарная физическая память процесса), который растёт через полные GC и никогда не возвращается вниз. Здоровый процесс пилит; текущий — лестничит. Смотри это напрямую через --trace-gc, который печатает по строке на сборку с размерами до/после.

node --trace-gc server.js
# [12345:0x...] 4210 ms: Mark-Sweep 1850.2 (2048.0) -> 1844.9 (2048.0) MB
#                                    ^ после полного GC почти не упало → утечка

Жёсткий потолок — --max-old-space-size=<МБ>. На 64-битном Node дефолт old space большой, но ограниченный (исторически ~2 ГБ; зависит от платформы и версии), и реальная нагрузка с большой легитимной кучей может потребовать его поднять. Но поднятие — это ручка тюнинга, а не фикс утечки: как показывает хук, удвоение лимита лишь удваивает время до OOM. Диагностический вопрос всегда один: возвращается ли память после полного GC? Если да — ты недопровиженен, подними лимит. Если нет — у тебя утечка, снимай снимки.

Раннбук триажа утечки

Когда память растёт и тебя OOM-килит, ходы механические, а не магические. Подтверди, что это утечка (old space не падает после полного GC по --trace-gc). Сними базовый снимок, жёстко нагрузи подозрительный путь, сними снова, повтори для третьего. Через вид сравнения «allocated between snapshots» найди конструктор, чей счётчик только растёт. Сортируй по retained size, открой retainer path и иди по нему к корневой ссылке — почти всегда это безграничный кэш, забытый слушатель, жирное замыкание или модульный глобал. Затем заставь ссылку исчезнуть: добавь LRU-вытеснение или TTL кэшу, removeListener/off при teardown, обнули захваченный объект. Перезапусти diff снимков, чтобы доказать, что счётчик теперь ровный. Регрессионный тест, утверждающий стабильный RSS после N итераций, не даёт ей вернуться.

// до: течёт по одной записи на запрос, вечно
const cache = new Map();
function handle(req) {
  cache.set(req.id, expensiveResult(req)); // никогда не вытесняется → OOM за часы/дни
}

// после: ограничено — старые ключи становятся недостижимы и GC их возвращает
import { LRUCache } from "lru-cache";
const cache = new LRUCache({ max: 10_000, ttl: 60_000 });
function handle(req) {
  cache.set(req.id, expensiveResult(req)); // вытесняет старейшие за 10k записей
}