API de nodo estable con 512 MB de RAM. Un mes después: PM2 se reinicia cada cuatro horas. Agregamos max_memory_restart=800M: reiniciamos el ciclo a cuarenta por minuto durante el pico del mediodía. Post-mortem: Map caché global indexado por ID de usuario sin desalojo, introducido con la funcionalidad de "sesiones temporales" - fuga lenta, invisible en una prueba de diez minutos.
El nodo no devuelve memoria de forma agresiva al sistema operativo; heapUsed puede fallar después de un recolector de basura. Una fuga es un crecimiento de tendencia bajo una carga representativa, no un pico posterior a la implementación. Reiniciar cada noche oculta el problema hasta que un día el intervalo ya no es suficiente.
Monitorear antes de reiniciar
Mide lo que importa:
| Métrica | Señal |
|---|---|
process.memoryUsage().heapUsed | Tendencia tras la recogida de basura |
| RSS | Es el RSS que está observando el asesino de OOM |
| Retraso del bucle de eventos | Fuga + carga = latencia del bucle de eventos |
| Frecuencia de las interrupciones del GC | Aumenta si la pila crece |
Herramientas comunes:
- Prometheus con node_exporter y métricas de aplicación
/metrics - PM2
pm2 monit,--max-memory-restartjunto con una alerta si el contador de reinicio aumenta - APM (Datadog, etc.) para correlacionar consultas lentas y de montón
Regla general: un reinicio programado de la máscara: establezca una alerta RSS > línea de base × 1,5 durante una hora antes de agregar un cron nocturno.
Reiniciar sin gráfico significa pagar la ambulancia sin diagnóstico.
Diagnóstico del montón
Procedimiento en puesta en escena y luego en producción fuera del pico:
- Reproducir una carga larga (k6 durante dos horas mínimo).
- Capture una instantánea del montón al principio y al final:
--inspecto--heapsnapshot-near-heap-limit(Nodo 18+). - Comparar en Chrome DevTools (Comparación): los objetos aumentan el recuento.
- Vuelva a ensamblar los retenedores (Cierre, Matriz, Buffer).
Causas frecuentes en la API web:
setIntervalnunca se cancela conclearIntervalsocket.onduplicado sinremoveListener- Objeto global
{ [reqId]: bigObject }nunca eliminado - Biblioteca de registro que mantiene referencias de contexto.
Límites de alojamiento y memoria
En contenedor o Kubernetes, el límite de memoria mata a Node mediante SIGKILL sin un cierre correcto. Dimensione el límite por encima del montón máximo más algo de margen para el código nativo, o solucione la fuga.
En VPS, el intercambio de ocultaciones acaba con el rendimiento: alerta en RSS, no solo en la CPU. Un proceso de Nodo único: la fuga afecta a todo el servicio. El modo de clúster PM2 no corrige la fuga, sino que la multiplica entre varios trabajadores.
Compare las ofertas de VPS adecuadas para Node a través del directorio y la comparación. Para la implementación, cruce con PM2 en producción.
PM2: reinicio versus corrección
max_memory_restart: aceptable temporalmente con un ticket de investigación prioritario.
Reinicio cron nocturno: tolerable si no se conoce ninguna fuga (el retorno de la memoria al sistema operativo es extraño); no sustituye a la corrección.
Combine max_restarts y exp_backoff_restart_delay para evitar bucles de reinicio que apagan WebSockets en la mitad del pico.
Lo mejor: el reinicio automático es una deuda que se acumula
Esto es lo que esconde PM2 cuando todo parece estable.
Cultura del equipo: instantánea del montón antes de agregar max_memory_restart, o al menos un ticket de causa raíz fechado.
Decide y avanza sin puntos ciegos
Antes de agregar un cron de reinicio:
- Gráfico RSS de siete días con tráfico normal: identifique la tendencia, no los picos aislados.
- Alerta sobre el contador de reinicios de PM2, no solo sobre la disponibilidad de HTTP.
- Prueba de carga larga en etapa de preparación: dos horas como mínimo para revelar una fuga lenta.
- Corregir los retenedores identificados en la instantánea: mapa sin TTL, oyentes ni temporizadores.
- Elimine el reinicio cron si la curva de memoria se estabiliza después de la corrección.
Consulte implementación de PM2 para conocer las mejores prácticas de monitoreo y el directorio para elegir un VPS con suficiente RAM para capturar una instantánea del montón de horas de menor actividad.
Preguntas frecuentes
¿Cómo detectar una pérdida de memoria de Node.js?
Observe RSS o heapUsed durante varias horas o días con tráfico estable. Si la curva sube sin bajar después de la recolección de basura, probable fuga. Un pico y luego una caída es normal; una meseta ascendente no lo es.
¿PM2 max_memory_restart es suficiente?
Esta es una solución provisional: se recicla antes de OOM pero pierde estado, oculta la causa raíz y puede generar un bucle. Combínelo con una alerta y una investigación del montón antes de considerar el problema resuelto.
¿volcado de montón en producción?
Posible temporada baja con --heapsnapshot-near-heap-limit (Nodo 18+) o el módulo heapdump activado manualmente. Analice en Chrome DevTools: evite el pico medio sin medir el impacto.
¿Fugas clásicas en la API web de Node?
Cierres que mantienen referencias de consultas, detectores de eventos no eliminados, caché de mapas sin vida útil, búferes agregados, temporizadores olvidados: cada uno de ellos deja una curva RSS que aumenta lentamente.
Monitorear la curva de memoria cuesta menos que un PM2 que se reinicia en un bucle el día que la fuga alcanza el cron.