El playbook de fugas de memoria en Node.js — heap snapshots, clinic.js y los cuatro patrones que seguimos encontrando

Las fugas de memoria de Node.js tienden a parecer aterradoras y normalmente no lo son. Los mismos cuatro patrones aparecen en auditoría tras auditoría: un Map/Set que crece sin límite, una closure que retiene un scope padre inesperadamente grande, event listeners enganchados pero nunca retirados, y un caché in-process sin política de evicción.

Este es el playbook de diagnóstico que ejecutamos en servicios Node de clientes que empiezan a comerse memoria semana tras semana.

Heap snapshots — el único diagnóstico que no es adivinanza

import v8 from 'node:v8';
import fs from 'node:fs';
 
process.on('SIGUSR2', () => {
  const file = `/tmp/heap-${Date.now()}.heapsnapshot`;
  v8.writeHeapSnapshot(file);
  console.log('wrote', file);
});

Envía SIGUSR2 al proceso, toma un snapshot, repite tras 30 minutos de tráfico, diff los dos en la pestaña Memory de Chrome DevTools. La columna retained-objects te dice exactamente qué está creciendo.

El artículo completo cubre:

• Los cuatro patrones y cómo cada uno aparece en el diff del heap snapshot
• clinic.js doctor y clinic flame para CPU + memoria juntos
• --inspect y Chrome DevTools para profiling en vivo fuera de producción
• Ejecutar la detección de fugas contra tus propios servicios en CI antes de producción
• La lectura cgroups + OOMKiller cuando la fuga acabó en producción de todos modos
• Cuándo la «fuga» es en realidad la young generation de V8 que no colecta lo bastante rápido (no es una fuga)

Háblanos si tu servicio Node ha crecido silenciosamente y nadie sabe por qué.