Gestión de cargas JSON grandes y límites de memoria en nodos Code durante procesamiento por lotes

Preguntas
1

Hola a todos,

Actualmente estoy creando un flujo de trabajo de automatización en n8n para procesar cargas de datos pesadas y me encuentro con un obstáculo de ejecución durante tareas de alto volumen.

Configuración actual:

  • Instancia n8n autohospedada que maneja flujos de datos de alta frecuencia provenientes de múltiples webhooks y puntos finales de API.

  • Uso de nodos de Código avanzados (JavaScript) para analizar, transformar y reestructurar objetos JSON profundamente anidados antes de enviarlos a aplicaciones posteriores.

El desafío:

A medida que aumentan los tamaños de lote, el uso de memoria de ejecución se incrementa significativamente. Ocasionalmente, arrays grandes de datos causan ralentizaciones en la ejecución o alcanzan límites al procesar estructuras de elementos masivas de una sola vez dentro de un bloque de ejecución de un nodo de Código.

¿Qué prácticas recomendadas o patrones de diseño de flujo de trabajo recomienda esta comunidad para dividir datos de manera eficiente, gestionar la sobrecarga de memoria u optimizar transformaciones de cargas útiles a gran escala en nodos de Código de n8n?

Me encantaría escuchar cualquier consejo o estrategia de escalado de sus entornos de producción. ¡Gracias!

2

Hola @Maaz, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:

Recursos sugeridos

Coincidencia automática con tu pregunta.

Documentación:

Foro:

@dmitrijz, @jabbson, @hubschrauber - han ayudado con problemas similares antes, ¿pueden echar un vistazo?

Sugerido automáticamente por el bot comunitario de n8n. Es un piloto - comparte comentarios aquí.

3

Hola @Maaz
Loop Over Items por sí solo no reducirá el pico de memoria, el nodo mantiene la entrada original y recombina cada lote procesado en la salida completada, así que el conjunto de datos completo sigue dentro de una ejecución. En su lugar, mueve la transformación: Loop Over Items con un tamaño de lote en los cientos bajos, luego Execute Sub-workflow, con el trabajo del nodo Code viviendo en el sub-workflow y devolviendo solo un conjunto de resultados pequeño al padre (ids, conteos, un estado). La memoria se libera después de cada lote en lugar de mantener cada elemento a la vez.
Ejecuta estos a través del trigger y no de ejecuciones manuales, las ejecuciones manuales hacen que n8n copie los datos para el frontend además de lo que la ejecución ya mantiene.
Si estás dimensionando la caja para este tipo de carga, esto lo cubre: