Nous avons beaucoup de nouveaux développeurs sur notre serveur n8n. Avec l’augmentation des utilisateurs et des requêtes de données plus importantes, je cherche des améliorations pour la scalabilité. Je fais actuellement tourner n8n sur Windows via Node avec une base de données PostgreSQL sur le même serveur.
Je veux passer à Docker et au mode queue pour pouvoir augmenter le nombre de workers.
Cela aidera-t-il à réduire l’impact d’un workflow de données volumineux, permettant aux autres workers de continuer à fonctionner correctement si l’un d’eux se bloque ? Pour le moment, tout le serveur ralentit ou rencontre une erreur JavaScript heap out of memory.
Merci
Jason
Salut @jbenway
En ce moment, ta configuration n’8n ressemble à une petite boutique où une seule personne répond au téléphone, prend les commandes et prépare les plats. Si une commande massive et compliquée arrive, cette personne devient vite débordée, le téléphone n’est plus répondu, et toute la boutique s’arrête jusqu’à ce que la commande soit terminée ou que la personne s’effondre d’épuisement.
Passer au « Mode Queue » c’est comme embaucher un gérant et une équipe de cuisiniers. Le gérant (le processus principal) gère uniquement le téléphone et l’emploi du temps, tandis que les cuisiniers (les Workers) font la vraie cuisine en arrière-cuisine. Cela signifie que même si un cuisinier est en difficulté avec une énorme commande, le gérant peut toujours parler aux clients, et les autres cuisiniers peuvent continuer à préparer les petites commandes sans aucun délai.
Cela résout aussi tes plantages mémoire. Au lieu d’un énorme réservoir mémoire partagé par tout le monde, chaque cuisinier dispose de son propre espace de travail dédié. Si un workflow particulier est tellement volumineux qu’il plante un worker, cela ne tue que ce seul « cuisinier ». Le reste du système reste en ligne, et le worker qui a planté peut être redémarré automatiquement sans affecter les autres utilisateurs.
En résumé, bien que cette configuration soit un peu plus complexe à mettre en place parce que tu dois ajouter un outil appelé Redis pour coordonner le travail, c’est la seule façon de supporter une équipe en croissance. Elle transforme ton serveur d’un point unique de défaillance fragile en un système professionnel qui peut grandir avec l’augmentation de tes données et du nombre d’utilisateurs.
Oui, cela aidera. Mais ce n’est pas une solution miracle.
Avec le mode queue, tu as effectivement plus d’options pour répartir la charge et tu peux régler le problème avec ça. Ce ne sera peut-être pas aussi simple que simplement l’activer non plus, parce que tu mentionnes des problèmes de mémoire.
salut @jbenway !
Linux + Docker est la réponse.
Oui, le mode queue résoudra votre problème spécifique, qui est qu’un seul workflow lourd bloque tout le reste pour vos autres développeurs. L’analogie du restaurant ci-dessus est juste : en ce moment, une seule grosse requête de données monopolise le seul processus et tout le monde d’autre attend. Le mode queue vous permet d’ajouter des workers pour qu’une tâche lourde occupe un seul worker tandis que les autres continuent à servir.
Quelques détails spécifiques pour votre configuration. Passer de Windows-node à Docker en vaut la peine en soi, le chemin Docker est celui qui est supporté et prévisible, et le mode queue est beaucoup plus facile à exécuter là. Conservez Postgres, mais envisagez de le déplacer en dehors du même serveur que n8n une fois que vous agrandissez vos workers, car si la DB et les workers se disputent le même CPU et la même mémoire, vous ne faites que déplacer le goulot d’étranglement. Commencez avec deux ou trois workers et observez l’utilisation des ressources plutôt que de sur-provisionner.
Une chose que le mode queue ne règle pas : un seul workflow qui tire un énorme dataset en mémoire en une seule exécution surchargeera toujours un worker. Donc en parallèle du déplacement, regardez si ce workflow avec de grandes données peut traiter par lots ou pousser la requête lourde vers Postgres plutôt que de tout charger dans n8n. Le mode queue empêche ça de bloquer les autres, le traitement par lots empêche ça de surcharger le worker sur lequel ça atterrit. Que fait exactement ce workflow lourd, une grosse requête puis du traitement, ou de la gestion de grands fichiers ?
Merci à tous pour vos retours.
Il semble que je sois sur la bonne voie pour dimensionner notre environnement.
Je ne travaille pas directement avec tous nos développeurs et je ne suis pas impliqué dans les données qu’ils envoient via n8n. J’ai observé les logs n8n en espérant trouver quelque chose qui m’indiquerait quels workflows consomment le plus de ressources et causent des surcharges (déconnexion), mais je n’ai rien trouvé pour l’instant.
Il semble que je pourrais avoir mon environnement Docker prêt pour lancer cette migration la semaine prochaine. Croisez les doigts pour moi !
Jason
Bonne chance @jbenway
Si vous avez trouvé votre solution ici, veuillez marquer la meilleure réponse comme solution pour soutenir la communauté. Cordialement
Salut @jbenway
En lisant ta description, je me retrouve essentiellement dans la même situation que toi : un nombre croissant de développeurs et de workflows, plus quelques tâches « lourdes » qui peuvent exercer une pression notable sur une seule instance n8n. Je fais également tourner n8n sur une seule machine (avec Postgres sur la même boîte), et j’ai vu comment un grand workflow de traitement de données peut ralentir tout ou déclencher une erreur JavaScript heap out‑of‑memory quand il essaie de faire trop de choses à la fois.
D’après ma compréhension et mes expériences jusqu’à présent, passer à Docker + queue mode aide vraiment pour la préoccupation exacte que tu as mentionnée :
-
Le processus main se concentre sur les webhooks, les déclencheurs et la planification.
-
Un ou plusieurs workers effectuent l’exécution réelle dans des processus Node.js séparés.
Donc si un workflow lourd se comporte mal sur un worker, cela affecte principalement ce worker, tandis que l’instance principale et les autres workers peuvent continuer à fonctionner. C’est déjà une grosse amélioration par rapport à un seul processus où l’UI, les déclencheurs et l’exécution vivent ensemble.
Cela dit, je ne le traiterais pas comme une solution miracle. Queue mode ne corrigera pas automatiquement les workflows qui essaient de charger ou de traiter d’énormes jeux de données en une seule exécution. Tu dois encore vérifier :
-
Combien de données une seule exécution conserve en mémoire.
-
Si tu peux traiter par lots ou en streaming au lieu de faire tout à la fois.
-
Une concurrence raisonnable par worker pour ne pas surcharger ta base de données ou tes systèmes aval.
Mon propre plan est :
-
Passer à Docker avec 1 main + quelques workers sur le même serveur pour obtenir de l’isolation et des limites CPU/mémoire plus claires par processus.
-
Commencer à utiliser queue mode pour que les exécutions lourdes soient poussées vers les workers au lieu de bloquer l’instance principale.
-
Ajuster progressivement la conception des workflows et la concurrence une fois que je vois comment le nouveau setup se comporte sous charge réelle.
En résumé : oui, Docker + queue mode devrait réduire le rayon d’impact d’un seul grand workflow et rendre le système beaucoup plus stable, tant que tu profites aussi de l’occasion pour repenser la manière dont les workflows les plus lourds gèrent les données.