Problema de memoria insuficiente

Preguntas
1

Hola comunidad de n8n,

Estoy enfrentando un grave problema de memoria insuficiente en mi instancia de n8n Cloud después de la reciente actualización de seguridad de n8n.

Mis flujos de trabajo funcionaban perfectamente hasta el 25 de junio y habían estado ejecutándose de manera confiable durante los últimos 7 meses. No realicé cambios en flujos de trabajo, nodos, credenciales, configuración o variables de entorno durante la semana pasada.

Después de la reciente actualización de versión de seguridad de n8n, múltiples flujos de trabajo de producción comenzaron a fallar durante la ejecución. Cuando estos flujos se ejecutan, la instancia se vuelve inestable o no responde, las automatizaciones dejan de ejecutarse y la instancia finalmente se queda sin memoria.

Ya he intentado eliminar ejecuciones guardadas, reducir el historial de ejecuciones y remover nodos Wait para reducir el uso de memoria, pero el problema persiste. Incluso después de eliminar las ejecuciones, cuando los flujos se ejecutan nuevamente, la instancia sigue quedándose sin memoria o falla.

El mismo problema también ocurrió en mayo después de una actualización de n8n Cloud. En ese momento, mis flujos de trabajo también habían sido estables durante varios meses sin cambios de mi parte, pero después de la actualización la instancia comenzó a fallar con errores de falta de memoria. El problema se resolvió eventualmente cuando n8n actualizó la instancia. Ahora, después de la última actualización, estoy enfrentando el mismo tipo de problema nuevamente.

Esto comenzó solo después de la reciente actualización, así que quiero entender si hubo algún cambio reciente en n8n Cloud relacionado con el manejo de memoria, comportamiento de ejecución, ejecuciones secundarias, concurrencia de flujos de trabajo o comportamiento de nodos.

Agradecería orientación del equipo de n8n o de la comunidad sobre cómo depurar esto e identificar qué está causando el pico de memoria.

También me gustaría saber si alguien más está enfrentando el mismo problema después de la actualización reciente, o si esto solo está sucediendo en mi instancia.

Salida devuelta por el último nodo

Los flujos de trabajo fallan antes de completarse exitosamente. El estado de ejecución muestra Error, y el problema principal es el comportamiento de falta de memoria a nivel de instancia.

En algunos casos, las ejecuciones fallan muy rápidamente, por ejemplo en milisegundos. En otros casos, se ejecutan durante varios segundos antes de fallar.

La instancia también se vuelve inestable o no responde cuando se ejecutan los flujos de trabajo.

Información sobre mi configuración de n8n

Versión de n8n: versión más reciente actualizada de n8n Cloud
Base de datos: base de datos gestionada de n8n Cloud
Configuración EXECUTIONS_PROCESS de n8n: gestionada por n8n Cloud / no configurada directamente por mí
Ejecutando n8n a través de: n8n Cloud
Sistema operativo: gestionado por n8n Cloud / no aplicable

Notas adicionales

Los flujos de trabajo eran estables antes de la actualización reciente. Este problema comenzó después de la actualización, sin cambios de mi parte.

Me gustaría saber:

  1. ¿Hubo alguna actualización reciente de n8n que cambió el uso de memoria, el manejo de ejecuciones, la concurrencia de flujos de trabajo o el comportamiento de nodos?

  2. ¿Hay alguna solución temporal, parche, opción de reversión o configuración recomendada para estabilizar la instancia?

  3. Como el mismo problema ocurrió en mayo después de una actualización de n8n y se resolvió por parte de n8n, ¿puede el equipo verificar si este es un problema similar a nivel de instancia o relacionado con la versión?

2

@Asher_TMT algunas personas han experimentado este mismo OOM posterior a la actualización en Cloud, así que apunta a una regresión de memoria en la versión a la que se te actualizó automáticamente, no a nada que hayas cambiado. ¿Qué versión tenía Cloud antes y después alrededor del 25, eso lo aclara? En términos del mecanismo, n8n mantiene todos los datos de elementos en memoria durante toda la ejecución, así que una compilación que carga más por elemento hace que los flujos de trabajo que estaban bien dimensionados se desborden. Como limpiar el historial guardado no ayudó, tu palanca está en la memoria en tiempo de ejecución, no en el historial almacenado: elimina campos grandes con un nodo Set entre los nodos pesados y divide los pasos más pesados en sub-flujos de trabajo para que cada uno tenga su propio alcance de memoria.

3

Este patrón merece tomarse en serio: estable durante 7 meses, sin cambios de tu lado, se rompe justo después de una actualización de plataforma, y exactamente lo mismo ocurrió en mayo y se resolvió cuando n8n actualizó tu instancia. Esa correlación apunta mucho más a una regresión a nivel de instancia/versión que a tus workflows. Algunos pensamientos, divididos en “lo que solo n8n puede hacer” y “lo que puedes hacer para reducir el problema”.

Escálalo directamente — este es el camino real hacia la solución. Como estás en n8n Cloud, las cosas que realmente resuelven los problemas de memoria a nivel de instancia (un parche, una reversión o actualizar la instancia) están del lado de n8n, no del tuyo — exactamente como en mayo. Abre un ticket de soporte y referencias explícitamente el incidente de mayo (mismo síntoma, resuelto cuando n8n actualizó la instancia), más la fecha en que comenzó (25 de junio) y la versión antes/después. Ese enfoque tiende a encaminarlo como una regresión en lugar de una pregunta de configuración.

Mientras tanto, reduce el culpable — esto te mantiene funcionando y le da a soporte una solución más rápida:

  • Encuentra el workflow ofensivo. En Executions, alinea los timestamps de los bloqueos contra qué workflow se estaba ejecutando. Un pico de memoria casi siempre se remonta a uno o dos workflows, no a todos.
  • Culpables de memoria habituales (una actualización puede cambiar el comportamiento del nodo lo suficiente como para llevar un workflow previamente funcional más allá del límite): cargas grandes mantenidas en memoria (respuestas HTTP grandes, archivos binarios/imágenes/PDFs llevados a través de muchos nodos), bucles / SplitInBatches que acumulan todos los elementos en lugar de procesarlos en fragmentos, y ejecuciones secundarias de sub-workflow (“Execute Workflow”) multiplicándose bajo concurrencia.
  • Aísla por desactivación. Desactiva temporalmente los workflows más pesados / más frecuentes uno a uno y observa cuándo la instancia se estabiliza — eso identifica la causa rápidamente.
  • Una palanca que la gente olvida: más allá del historial de ejecución global, verifica la configuración propia de cada workflow pesado y establece “Save execution progress” en off y “Save successful executions” en off. Guardar el progreso escribe los datos de cada nodo y es un costo real de memoria en workflows con cargas grandes. Ya recortaste el historial global, pero esta configuración por workflow es separada.
  • Para workflows con muchos datos, pagina / agrupa para que nunca mantengas todo el conjunto de datos en memoria a la vez, y evita pasar archivos binarios a través de más nodos de lo necesario.

Para acelerar el ticket, proporciónales: la versión exacta antes/después, la fecha de inicio, la referencia del ticket de mayo, el workflow específico + nodo, un par de IDs de ejecución bloqueados, y si está vinculado a ejecuciones concurrentes. Eso generalmente es suficiente para que lo reproduzcan.

Dado el precedente de mayo, mi lectura honesta es que lo más probable es que esto sea algo que n8n necesite parchear en su lado — pero los pasos anteriores deberían mantenerte estable y hacer la solución más rápida de cualquier forma.

4

El ángulo de regresión de memoria suena plausible, especialmente si nada cambió en tus flujos de trabajo y las fallos comenzaron justo después de la actualización de Cloud. El camino técnico inmediato es reducir la memoria en ejecución: elimina campos grandes lo antes posible, divide ramas pesadas en subflujos de trabajo, evita llevar cargas útiles completas a través de nodos posteriores, y aísla el flujo de trabajo que primero consume mucha memoria.

Para flujos de trabajo en producción, también manejaría esto como un incidente, no solo como una tarea de depuración:

  1. Lista qué flujos de trabajo están fallando y qué clientes/procesos afectan.
  2. Registra cuándo comenzó el problema y qué versión de n8n cambió.
  3. Añade una verificación temporal que confirme que los flujos de trabajo críticos se están completando.
  4. Documenta la mitigación que aplicaste, como eliminación de campos o división en subflujos de trabajo.
  5. Decide si el cliente/interesado necesita una actualización de estado.

El riesgo operacional es que múltiples flujos de trabajo fallen silenciosamente mientras todos se enfochan en la causa raíz. Mantén un registro breve de problemas hasta que la plataforma sea estable nuevamente.