Tenemos muchos desarrolladores nuevos en nuestro servidor n8n. Con el aumento de usuarios y consultas de datos más grandes, estoy buscando mejoras de escalabilidad. Actualmente estoy ejecutando n8n en Windows a través de node con una base de datos PostgreSQL en el mismo servidor.
Quiero pasar a dockers y modo de cola para poder aumentar el número de workers.
¿Eso ayudará a reducir el impacto de un flujo de trabajo con grandes volúmenes de datos, permitiendo que los otros workers continúen mientras uno se bloquea? Ahora mismo todo el servidor se ralentiza o tendrá un error de JavaScript heap out of memory.
Gracias
Jason
Hola @jbenway
En este momento, tu configuración de n8n es como una tienda de una sola persona donde la misma persona contesta el teléfono, toma la orden y cocina la comida. Si llega una orden masiva y complicada, esa persona se siente abrumada, el teléfono deja de contestarse y toda la tienda se detiene hasta que se termina la orden o la persona se colapsa por agotamiento.
Pasar a «Queue Mode» es como contratar a un gerente y un equipo de chefs. El gerente (el proceso principal) solo maneja el teléfono y el horario, mientras que los chefs (los Workers) hacen la cocina real en la cocina. Esto significa que aunque un chef esté lidiando con una orden gigantesca, el gerente aún puede hablar con los clientes, y los otros chefs pueden seguir sacando órdenes más pequeñas sin ningún retraso.
Esto también soluciona tus bloqueos de memoria. En lugar de un gran depósito de memoria que todos comparten, cada chef obtiene su propio espacio de trabajo dedicado. Si un flujo de trabajo específico es tan grande que hace que un worker se bloquee, solo mata ese «chef». El resto del sistema permanece en línea y el worker que se bloqueó puede reiniciarse automáticamente sin afectar a ningún otro usuario.
En resumen, aunque esta configuración es un poco más compleja de construir porque tienes que añadir una herramienta llamada Redis para coordinar el trabajo, es la única manera de apoyar a un equipo en crecimiento. Transforma tu servidor de un punto único de fallo frágil en un sistema profesional que puede crecer a medida que aumentan tus datos y la cantidad de usuarios.
Sí, ayudará. Pero no es una solución milagrosa.
Con el modo de cola tienes más opciones para distribuir la carga y puedes solucionarlo con eso. Sin embargo, podría no ser tan simple como solo activarlo, especialmente porque mencionas problemas de memoria.
¡oi @jbenway!
Linux + Docker es la respuesta.
Sí, el modo de cola te ayudará con tu problema específico, que es un flujo de trabajo pesado bloqueando todo lo demás para tus otros desarrolladores. La analogía del restaurante de arriba es correcta: ahora mismo una consulta de datos grande ocupa el único proceso y todos los demás esperan. El modo de cola te permite añadir workers para que un trabajo pesado ocupe un worker mientras los otros siguen sirviendo.
Algunos detalles específicos para tu configuración. Pasar de Windows-node a Docker merece la pena por sí solo, la ruta de Docker es la soportada y predecible, y el modo de cola es mucho más fácil de ejecutar ahí. Mantén Postgres, pero considera moverlo del mismo servidor que n8n una vez que escales workers, porque si la BD y los workers compiten por la misma CPU y memoria solo estás moviendo el cuello de botella. Comienza con dos o tres workers y observa el uso de recursos en lugar de sobre-aprovisionar.
Una cosa que el modo de cola no soluciona: un flujo de trabajo único que extrae un conjunto de datos enorme a la memoria en una ejecución seguirá tensionando un worker. Así que junto con el cambio, considera si ese flujo de trabajo con muchos datos puede procesarse en lotes o si puedes empujar la consulta pesada hacia Postgres en lugar de cargar todo en n8n. El modo de cola evita que bloquee a los otros, los lotes evitan que tense el worker en el que cae. ¿Qué hace realmente el flujo de trabajo pesado, una consulta grande y luego procesamiento, o manejo de archivos grandes?
Gracias a todos por vuestras aportaciones.
Parece que voy por el buen camino para escalar nuestro entorno.
No trabajo directamente con todos nuestros desarrolladores ni estoy involucrado en los datos que envían a través de n8n. He estado observando los registros de n8n con la esperanza de encontrar algo que me indique qué flujos de trabajo están consumiendo más recursos y causando que se quede ocupado (desconexión), pero aún no lo he encontrado.
Parece que podría tener mi entorno docker listo para iniciar esta migración la próxima semana. ¡Desead me suerte!
Jason
Buena suerte @jbenway
si encontraste tu solución por aquí, por favor marca la mejor respuesta como solución para apoyar a la comunidad. saludos cordiales
Hola @jbenway
Leyendo tu descripción, estoy esencialmente en la misma situación que tú: un número creciente de desarrolladores y flujos de trabajo, además de algunos trabajos “pesados” que pueden ejercer una presión notable en una única instancia de n8n. También estoy ejecutando n8n en una sola máquina (con Postgres en la misma caja), y he visto cómo un flujo de trabajo de datos grande puede ralentizar todo o incluso disparar un error de JavaScript heap out-of-memory cuando intenta hacer demasiado de una sola vez.
Según mi comprensión y experimentos hasta ahora, pasar a Docker + modo de cola sí ayuda exactamente con la preocupación que mencionaste:
-
El proceso main se enfoca en webhooks, disparadores y programación.
-
Uno o más workers realizan la ejecución real en procesos separados de Node.js.
Así que si un flujo de trabajo pesado se comporta mal en un worker, principalmente afecta a ese worker, mientras que la instancia main y los otros workers pueden seguir funcionando. Eso ya es una gran mejora comparado con un solo proceso donde la UI, los disparadores y la ejecución viven todos juntos.
Dicho esto, no lo trataría como una solución milagrosa. El modo de cola no arreglará automáticamente los flujos de trabajo que intentan cargar o procesar conjuntos de datos enormes en una ejecución. Aún necesitas revisar:
-
Cuántos datos mantiene un solo ejecutable en memoria.
-
Si puedes agrupar o transmitir el trabajo en lugar de hacer todo de una sola vez.
-
Una concurrencia razonable por worker para que no sobrecargues tu base de datos o sistemas posteriores.
Mi propio plan es:
-
Pasar a Docker con 1 main + un par de workers en el mismo servidor para obtener aislamiento y límites más claros de CPU/memoria por proceso.
-
Comenzar a usar modo de cola para que las ejecuciones pesadas se envíen a los workers en lugar de bloquear la instancia main.
-
Ajustar gradualmente el diseño del flujo de trabajo y la concurrencia una vez que vea cómo se comporta la nueva configuración bajo carga real.
Así que en resumen: sí, Docker + modo de cola debería reducir el radio de impacto de un único flujo de trabajo grande y hacer que el sistema se sienta mucho más estable, siempre y cuando también aproveches la oportunidad para repensar cómo los flujos de trabajo más pesados manejan los datos.