Wir haben viele neue Entwickler auf unserem n8n-Server. Mit den zunehmenden Benutzern und größeren Datenabfragen suche ich nach Verbesserungen für die Skalierbarkeit. Derzeit führe ich n8n unter Windows über Node mit einer PostgreSQL-DB auf demselben Server aus.
Ich möchte zu Docker und zum Queue-Modus wechseln, damit ich die Worker-Anzahl erhöhen kann.
Wird das helfen, die Auswirkungen eines großen Daten-Workflows zu reduzieren, damit die anderen Worker weiterhin gut funktionieren, wenn einer steckenbleibt? Derzeit wird der ganze Server verlangsamt oder es kommt zu einem JavaScript-Heap-Out-of-Memory-Fehler.
Momentán ist dein n8n-Setup wie ein One-Person-Laden, in dem dieselbe Person das Telefon beantwortet, Bestellungen aufnimmt und das Essen zubereitet. Wenn eine massive, komplizierte Bestellung kommt, wird diese Person überfordert, das Telefon wird nicht mehr beantwortet, und der ganze Laden bleibt stehen, bis die Bestellung fertig ist oder die Person vor Erschöpfung zusammenbricht.
Ja, das wird helfen. Aber es ist kein Allheilmittel.
Mit dem Queue-Modus hast du tatsächlich mehr Optionen, um die Last zu verteilen, sodass du das damit beheben kannst. Es ist aber möglicherweise nicht so einfach, es einfach zu aktivieren, auch weil du Speicherprobleme erwähnst.
Ja, der Queue-Modus hilft bei deinem spezifischen Problem, nämlich dass ein großer Workflow alles andere für deine anderen Entwickler blockiert. Die Restaurant-Analogie oben stimmt: Momentan bindet eine einzelne große Datenbankabfrage den einen Prozess und alle anderen müssen warten. Mit dem Queue-Modus kannst du Worker hinzufügen, sodass ein großer Job einen Worker beschäftigt, während die anderen weiterhin arbeiten.
Ein paar spezifische Punkte für dein Setup. Der Wechsel von Windows-Node zu Docker lohnt sich allein schon, der Docker-Weg ist der unterstützte und vorhersehbare und der Queue-Modus ist dort viel einfacher zu betreiben. Behalte Postgres, aber erwäge, es auf einen anderen Server als n8n zu verschieben, sobald du Worker skalierst, denn wenn die Datenbank und die Worker um dieselbe CPU und denselben Speicher konkurrieren, verschiebst du nur den Engpass. Fang mit zwei oder drei Workern an und beobachte die Ressourcennutzung, anstatt zu viel bereitzustellen.
Eine Sache, die der Queue-Modus nicht behebt: Ein einzelner Workflow, der eine riesige Datenmenge in einer Ausführung in den Speicher lädt, wird immer noch einen Worker belasten. Überprüfe also parallel zum Umzug, ob dieser Large-Data-Workflow in Batches verarbeitet werden kann oder ob die schwere Abfrage in Postgres bleiben kann, anstatt alles in n8n zu laden. Der Queue-Modus stoppt, dass es andere blockiert, Batching stoppt, dass es den Worker belastet, auf dem es landet. Was macht der schwere Workflow tatsächlich, eine große Abfrage und dann Verarbeitung oder großes Datei-Handling?
Es klingt, als wäre ich auf dem richtigen Weg, unsere Umgebung zu skalieren.
Ich arbeite nicht direkt mit allen unseren Devs zusammen und bin nicht an den Daten beteiligt, die sie über n8n versenden. Ich habe die n8n-Logs beobachtet, in der Hoffnung, etwas zu finden, das mir zeigt, welche Workflows die meisten Ressourcen nutzen und dazu führen, dass die Umgebung beschäftigt ist (disconnect), aber ich habe es bislang nicht gefunden.
Es sieht so aus, als könnte ich meine Docker-Umgebung nächste Woche für diese Migration vorbereitet haben. Drückt mir die Daumen!
Viel Erfolg @jbenway
Falls du deine Lösung hier gefunden hast, markiere bitte die beste Antwort als Lösung, um die Community zu unterstützen. Viele Grüße
Bei der Lektüre deiner Beschreibung stelle ich fest, dass ich mich in einer ähnlichen Situation befinde wie du: eine wachsende Anzahl von Entwicklern und Workflows, plus einige „schwere