Утечки памяти в production: как отлавливать то, что не видно в логах

Каждый раз, когда слышу "у нас утечка памяти", первая мысль - кто-то забыл удалить слушатель событий или не очистил setInterval. В production все сложнее: утечки копятся неделями, проявляются при определенной нагрузке, и локально их не воспроизвести.

Вот три рабочих инструмента.

Heap snapshots: как читать между строк

Снимаешь снапшот в Chrome DevTools (Memory -> Take heap snapshot). Сравниваешь два: до и после выполнения подозрительного сценария.

Ищешь объекты, которые:
- Не должны быть в памяти, но есть (старые DOM-ноды с замыканиями)
- Имеют неожиданно много экземпляров (10 000 объектов класса Widget)

Если видишь Closure с огромным retained size - это замыкание, которое держит ссылку на внешние данные. В production такая утечка часто возникает в SSR, когда обработчик запроса захватывает ссылку на глобальный кэш.

Memory tab: интерактивный детектив

Переходишь на вкладку Memory, выбираешь "Allocation instrumentation on timeline". Записываешь профиль при активной работе пользователя.

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

Паттерн, который ловил так: React-компонент, при каждом ререндере создавал новый объект-конфигурацию и передавал в children - GC не успевал чистить, через час работы страница весила 200+ МБ.

Автоматизированные паттерны детекции

Ручной анализ хорошо, но в production нужно автоматическое обнаружение. Два подхода.

Performance Observer с проверкой usedJSHeapSize:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  if (performance.memory?.usedJSHeapSize > 200_000_000) {
    console.warn('Memory warning', performance.memory);
  }
}).observe({ type: 'resource', buffered: true });

Только в Chrome с флагом enable-experimental-web-platform-features. Типичная ошибка - использовать это без fallback в Safari или Firefox.

Кастомный мониторинг:

setInterval(() => {
  const { usedJSHeapSize, totalJSHeapSize } = performance.memory;
  const usagePercent = (usedJSHeapSize / totalJSHeapSize) * 100;
  if (usagePercent > 80) {
    sendMetric('memory_leak_risk', usedJSHeapSize);
  }
}, 60000);

Не используй для продакшена бездумно - performance.memory есть не везде. Оборачивай в try/catch и делай fallback на navigator.userAgent.

Утечки в production - это не баги, а архитектурные проблемы. Если после каждого перехода по роуту память растет на 5-10% и не падает - ищи подписки в эффектах, которые не отписываются при размонтировании. Или глобальные кэши, которые никогда не чистятся.

Вывод: Надежная детекция утечек требует сочетания автоматических инструментов и ручного анализа heap snapshots, а не надежды на GC или банальные логи.