Workflow-Ausführung von n8n nach 3–6 Stunden ohne klaren Fehler an einem Node erzwungen gestoppt

Fragen
,
1

Ich habe meine Automatisierung veröffentlicht. Der Trigger ist ein Webhook-Node, wenn eine CSV-Datei (1000 Leads) an diesen Webhook gesendet wird, startet die Automatisierung, aber die Automatisierung wird von n8n erzwungen beendet. Beim ersten Mal lief sie 3 Stunden lang (verarbeitete 260 Leads), bevor sie erzwungen beendet wurde, und beim nächsten Versuch lief sie 6 Stunden lang [startete von vorne und verarbeitete 500 Leads], bevor sie erzwungen beendet wurde:

image
image380×174 7.07 KB

Ich versuche gerade einen dritten Versuch mit anderen Einstellungen, die folgende sind:

image
image1296×725 47 KB

bitte teilt mir mit, wenn jemand die wahrscheinliche Ursache und Lösung kennt

2

Hey @AbdullahShah, während du auf eine Antwort wartest, hier sind einige Dinge, die dir helfen könnten:

Vorgeschlagene Ressourcen

Automatisch zu deiner Frage abgestimmt.

Dokumentation:

Forum:

@alexm, @Mark_Tic, @Niffzy - ihr habt schon bei ähnlichen Problemen geholfen, könnt ihr da einen Blick drauf werfen?

Automatisch vorgeschlagen von n8ns Community-Bot. Das ist ein Pilotprojekt – bitte gebt hier Feedback.

3

Zwei Dinge kannst du direkt anhand deiner eigenen Screenshots ausschließen oder bestätigen.

Es ist nicht das Workflow-Timeout. Dein Settings-Screenshot zeigt „Timeout Workflow

4

Beide Fehler traten auf, bevor ich „Ausführungsfortschritt speichern

5

Hallo @AbdullahShah

Dein Workflow erleidet mit hoher Wahrscheinlichkeit einen Out of Memory (OOM)-Crash, weil n8n versucht, die Ausführungsdaten für alle 1000 Leads über jeden Knoten hinweg während eines mehrstündigen Durchlaufs gleichzeitig im RAM zu halten.

Du hast Ausführungsfortschritt speichern auf Speichern eingestellt.

  • Die Lösung: Ändere dies auf Standard - NICHT SPEICHERN.

  • Der Grund: Wenn diese Option aktiviert ist, schreibt n8n den Status von jedem einzelnen Knoten während des Durchlaufs kontinuierlich in die Datenbank. Bei einer 3 bis 6 Stunden dauernden Ausführung entsteht ein massiver Engpass, der sowohl RAM als auch deine PostgreSQL-/SQLite-Datenbank aufbläht, bis der Node.js-Prozess abstürzt oder der Container vom Host beendet wird.

image
image1165×681 46 KB

Die Ausführung von 1000 schweren Iterationen in einem einzelnen Workflow wird letztendlich den Node.js-Heap-Speicher erschöpfen, weil der Garbage Collector die Daten erst löschen kann, wenn die gesamte übergeordnete Ausführung beendet ist.

  • Die Lösung: Verwende einen Execute Workflow-Knoten, um die Leads in kleineren Batches an einen sekundären Workflow zu übergeben.

  • Der Grund: Wenn ein Sub-Workflow abgeschlossen wird, leert n8n seine Ausführungsdaten aus dem Speicher und hält den RAM-Footprint des übergeordneten Workflows klein.

6

Du hast recht, und mein Beitrag war da falsch. Dein erster Beitrag sagt, dass der dritte Durchlauf derjenige mit den neuen Einstellungen ist, also war „Save execution progress

7

Sowohl @kjooleng als auch @ClearStack haben den Nagel auf den Kopf getroffen, was den OOM-Crash und die Gefahr doppelter E-Mail-Versände angeht.

Wenn du 1000 Elemente in einer einzigen linearen Ausführung oder Schleife verarbeitest, sammelt Node.js alle Node-Input-/Output-Status im Speicher an. Die Garbage Collection kann Objekte erst bereinigen, wenn die gesamte übergeordnete Workflow-Ausführung abgeschlossen ist, was zu OOM-Kills auf dem Host führt.

Hier ist das 3-teilige Produktionsmuster zur Lösung sowohl des Speicherlecks als auch des doppelten E-Mail-Risikos:

### 1. Das Sub-Workflow-Batching-Muster (löst OOM)

Statt alle 1000 Leads in einer Schleife im übergeordneten Workflow auszuführen:

1. Verwende einen Split In Batches Node (Batch-Größe: 50-100 Elemente).

2. Übergebe jeden Batch an einen sekundären Worker-Workflow mit dem Execute Workflow Node.

3. Warum das funktioniert: Wenn die Ausführung jedes Sub-Workflows abgeschlossen ist, spült n8n sofort seinen RAM-Footprint und löst den Node.js Garbage Collector aus, wodurch die Speichernutzung über einen 6-Stunden-Lauf flach bleibt.

### 2. Idempotenzprüfung (verhindert doppelte E-Mail-Spam)

Wie @ClearStack richtig anmerkte: Wenn Ausführung #1 bei Lead 260 fehlschlägt und du neu startest, werden Leads 1-260 zweimal per E-Mail kontaktiert.

* Füge in deinem Sub-Workflow direkt vor dem Email Send Node einen If / Filter Node ein, der already_contacted === true prüft (oder deine DB nach email_sent_at IS NOT NULL abfragt).

* Wenn true → Überspringen.

* Wenn false → E-Mail senden und sofort DB-Status auf contacted aktualisieren.

### 3. Node.js Heap-Limit erhöhen (bei Self-Hosted / Docker)

Wenn du n8n selbst über Docker oder PM2 hostest, beträgt das Standard-Node.js-Heap-Speicherlimit etwa 2GB. Für lange laufende Batch-Jobs erhöhe es in deinen Umgebungsvariablen:

NODE_OPTIONS="--max-old-space-size=4096"

(Dies weist dem n8n-Prozess bis zu 4GB RAM zu).

Die Kombination von Sub-Workflows + Batching + Pre-send-Idempotenzprüfungen ist der Standard-Weg, um 10.000+ Lead-Pipelines auszuführen, ohne n8n zum Absturz zu bringen oder Benutzer zuzuspammen.

8

Hi @AbdullahShah
Den Upgrade-Badges in deinem Settings-Screenshot nach zu urteilen, nutzt du Cloud, wo die Obergrenze viel niedriger ist als bei einem Standard-Node-Prozess: Trial und Starter bekommen 320MiB, Pro-1 640MiB, Pro-2 1280MiB, und n8n selbst verbraucht davon etwa 180MiB, bevor dein Run startet. Eine Ausführung, die sechs Stunden lang offen bleibt und 1000 Leads verarbeitet, passt nicht in den verbleibenden Speicher.
Nimm die ganze Liste aus einer einzelnen Ausführung heraus. Lass den Webhook die 1000 Zeilen in ein Sheet oder eine Tabelle mit einer status-Spalte schreiben und beende dort, dann steuere das Senden von einem Schedule Trigger aus, der die ersten 25 Zeilen abruft, wo status leer ist, führt die Arbeit durch und schreibt sent zurück. Jede Ausführung dauert ein paar Minuten und gibt ihren Speicher frei, wenn sie endet, und ein Crash kostet nur einen Batch statt des ganzen Runs.

Wenn du überlegst, ob ein größerer Plan dir genug Spielraum bietet, werden hier die Tiers aufgeschlüsselt:

9

ok, ich teile meinen Workflow jetzt in einen Sub-Workflow auf, um zu sehen, ob das das OOM-Problem behebt. Kann mir jemand eine Sache klären? Muss ich den Sub-Workflow auch zusammen mit dem übergeordneten Workflow veröffentlichen?
mein Sub-Workflow:

Sub1 Non-DNC(1).json (526.6 KB)

mach dir keine Sorgen, dass ich denselben Lead zweimal kontaktiere, da ich diesen Workflow am Ende mit Instantly AI integriere und Instantly AI automatisch niemals Duplikate behält

10

Ja, sowohl der Parent-Workflow als auch der Sub-Workflow müssen veröffentlicht werden

11

Ich wollte nur diese Angelegenheit abschließen.

Der ursprüngliche Workflow wurde nach 3–6 Stunden ohne Node-Fehler zwangsbeendet, weil die gesamte Ausführung mit 1000 Leads den ganzen Zeit im Speicher behalten wurde (klassischer OOM auf n8n Cloud).

Ich habe es jetzt aufgesplittet: Das Parent macht nur Webhook → CSV-Extraktion → Google Sheet → DNC-Filter → Split In Batches (Größe 1) → Execute Workflow. Die ganze schwere Arbeit (Perplexity-Recherche + 5× GPT-4-Scoring + E-Mail-Generierung + Instantly-Push) läuft in zwei veröffentlichten Sub-Workflows, die jeweils einen Lead bearbeiten und den Speicher freigeben, wenn jeder fertig ist.

Ich teste derzeit mit 500 Leads.

Frage an die erfahrenen Leute hier: Mit dieser Architektur kann ich sicher eine einzelne CSV mit 5.000–6.000 Leads durch den Webhook pushen, oder sollte ich die Liste trotz des Sub-Workflow-Musters noch in kleinere Dateien aufteilen (z. B. 1.000 auf einmal)? Gibt es eine praktische Obergrenze, die ich auf Cloud noch beachten sollte?

Danke im Voraus.

12

Obwohl die untergeordneten Workflows speichereffizient sind, ist der übergeordnete Workflow nicht speichereffizient. Wenn du die Knoten „Read Binary File

13

Wollte nur die Sache hier abschließen.

Das ursprüngliche Problem war, dass der Workflow von n8n nach 3–6 Stunden ohne Fehler in einem Knoten einfach gestoppt wurde. Es stellte sich als klassisches Out-of-Memory-(OOM-)Problem heraus – n8n speicherte alle verarbeiteten Lead-Daten für die gesamte Dauer des Laufs im Speicher.

Die Lösung war, den Workflow in Sub-Workflows aufzuteilen. Alles, das nach dem Loop-Knoten kam, wurde in einen Sub-Workflow verschoben. Auf diese Weise behält der Parent-Workflow nur die aktuellen Verarbeitungsdaten im Speicher, und die umfangreiche Arbeit (sowie die bereits verarbeiteten Lead-Daten) wird freigegeben, sobald jeder Sub-Workflow fertig ist.

Durch diese Änderung kann die Automation jetzt komfortabel CSVs mit 1000–2000 Leads verarbeiten, was ein großer Sprung von dem bisherigen Maximum von etwa 300–400 Leads vor dem OOM ist.

Herzlichen Dank an alle in dieser Community, die mir geholfen haben, das Problem zu diagnostizieren und mich in die richtige Richtung gewiesen haben. Ich bin wirklich dankbar für die Unterstützung .. Gott segne euch alle, danke euch, Brüder!