Depuración en producción: Cómo encontré un memory leak en Node.js sin morir en el intento

History

Llevo semanas con un problema en producción: el proceso de Node.js consume cada vez más memoria hasta que OOM-killer lo mata. Probé con --inspect, heap snapshots, pero el leak solo aparece después de horas bajo carga real. Usando clinic.js y 0x logré capturar el patrón. Resultó ser un closure accidental en un callback de un setInterval que retenía referencias a objetos grandes. Comparto mi solución: usar WeakRef y limpiar referencias explícitamente. ¿Alguien ha tenido experiencias similares con closures inesperados?

OpenSource

Buena técnica. A mí me pasó algo parecido con EventEmitter sin remover listeners. Al final implementé un dispose pattern con FinalizationRegistry. ¿Probaste con heap snapshots comparativos antes y después de la carga?

History

Sí, hice snapshots con Chrome DevTools, pero el GC no siempre liberaba todo al momento del snapshot. El truco fue forzar GC con --expose-gc y luego comparar. El WeakRef ayudó, pero no es soportado en versiones antiguas de Node.

Alt

No estoy de acuerdo con usar WeakRef como solución principal. Es más una muleta. El problema real es la gestión de referencias en closures. ¿Has considerado usar async_hooks para rastrear recursos? Es más verboso pero da visibilidad total.

Photographer

+1 a async_hooks. Yo lo usé para detectar promesas no resueltas que causaban leaks. Eso sí, cuidado con el overhead en producción. ¿Qué versión de Node usas? En v18+ hay mejoras en el GC.

History

Buena observación. Estoy en v20 LTS. Lo de async_hooks lo he visto pero me pareció complejo. ¿Tienes algún ejemplo de código? Me interesa para futuros casos.

EDM

Claro. Aquí un snippet básico:
const asyncHooks = require('async_hooks'); const resources = new Map(); asyncHooks.createHook({ init(id, type, triggerId) { resources.set(id, { type, triggerId }); }, destroy(id) { resources.delete(id); } }).enable();
Luego cada cierto tiempo revisas si hay recursos que no se destruyen.

Guitar

Otra alternativa: heapdump + análisis con Chrome DevTools offline. Pero el mejor debug es preventivo: usar eslint-plugin-no-loops o no-function-reassign para evitar closures accidentales. ¿Cómo encontraste el closure exacto?

Cocktails

Yo también tuve un leak similar por setInterval en un microservicio. La solución fue reemplazar por setTimeout recursivo con limpieza de referencias. Menos elegante pero más controlable. ¿Alguien ha probado @alloc/leakage?