AI Agent + Code node OOM-Crash mit ~1-2MB Binary auf Cloud Starter — nicht-deterministischer Crash-Punkt, keine Abstürze auf Self-Hosted

Fragen
,
1

Zusammenfassung

Ich erlebe reproduzierbare OOM-Abstürze auf n8n Cloud Starter bei sehr kleinen Payloads (~1-2 MB binär). Der Absturzpunkt schwankt zwischen Code-Node und AI Agent zwischen Durchläufen mit derselben Eingabe, was stark auf Ressourcenfluktuationen von gemeinsamen Workern statt auf einen Benutzercode-Bug hindeutet.

Derselbe Workflow-JSON läuft perfekt auf selbstgehostet (Docker, 8 GB Host) — 30+ Ausführungen ohne Abstürze.

Umgebung

  • Plan: Cloud Starter
  • Instance: verma-digital.app.n8n.cloud
  • n8n Version: 2.20.7 (Cloud)
  • Node: @n8n/n8n-nodes-langchain.agent v1.8
  • Modell: gpt-4-1-mini

Reproduzierbarer Test — minimaler 8-Node-Workflow

Manuel Trigger
  → Code „Testdaten vorbereiten"
      (hole jede URL über helpers.httpRequest({encoding:'arraybuffer'})
       + helpers.prepareBinaryData, emit 1 Element pro Datei mit binär)
  → Switch nach MIME (PDF / Bild / Fallback)
  → Aus PDF extrahieren (nur PDF-Branch)  → Zusammenführen (anfügen, 3 Eingaben)
  → Code „Aggregieren"
      (sammle Elemente in einzelne Ausgabe: json.text + binary.data_0,
       data_1, ... für AI Agent)
  → AI Agent (passthroughBinaryImages: true)
  → OpenAI Chat Model

Kein Postgres-Speicher, keine Tools, keine gespeicherten Subworkflows. So minimal wie möglich, während das Problem noch reproduziert wird.

Ich kann gerne die vollständige Workflow-JSON teilen.

Testergebnisse

Eingabe Gesamtgröße binär Ergebnis
2 kleine Icons (webp) ~40 KB :white_check_mark: Immer erfolgreich
2 kleine PDFs (176 + 63 KB) ~240 KB :white_check_mark: Immer erfolgreich
1 PDF (2,6 MB, 5 Seiten) ~2,6 MB :cross_mark: Absturz
2 Bilder (1,56 MB + 810 KB webp) ~2,4 MB :cross_mark: Absturz

Der Schwellenwert liegt irgendwo zwischen ~240 KB und ~2,4 MB gesamtes Binär in einer einzelnen Ausführung. Der Absturz passiert sogar mit einem einzelnen 2,6-MB-Binär (nur ein helpers.httpRequest-Aufruf), daher ist dies nicht ein kumulatives Multi-Fetch-Speicherleck.

Der interessante Teil — nicht-deterministischer Absturzpunkt

Dieselbe exakte Eingabe, derselbe Workflow, derselbe Ausführungspfad:

  • Durchlauf 1: Absturz bei Code-Node „Testdaten vorbereiten
3

@sawsew467 deine Diagnose stimmt — Starter hat einen engen Memory-Limit pro Ausführung und du stackst binäre Daten + Base64-codierte Bilder (passthroughBinaryImages bläht ~33% auf) + Code-Node-Aggregation, alles gleichzeitig im Memory. Self-hosted mit 8GB hat einfach viel mehr Spielraum. Schnellste Lösung ohne Plan-Upgrade: passthroughBinaryImages weglassen und stattdessen Bild-URLs an den Agent übergeben — das Modell holt sie ab, dein Execution-Memory bleibt flach. Wie viele Bilder pro Ausführung typischerweise? Macht einen Unterschied, ob URL-Pass funktioniert oder du eine ganz andere Struktur brauchst.

4

Hi @sawsew467

Die Abstürze treten auf, weil der n8n Cloud Starter-Plan ein viel kleineres Speicherlimit hat als erwartet – nur 320 MB RAM statt 1 GB. Wenn du Dateien verarbeitest (wie PDFs oder Bilder), erstellt n8n nicht einfach nur eine Kopie der Datei; im Hintergrund werden mehrere Kopien erstellt und in ein textbasiertes Format (Base64) konvertiert, damit die KI sie lesen kann, was die Speichernutzung massiv erhöht. Da du direkt an der Grenze dieses Limits arbeitest, stürzt das System zufällig bei dem Node ab, der während dieses spezifischen Durchlaufs den Speicher über das Limit treibt.

Da dein Workflow auf deinem selbst gehosteten Server mit mehr RAM perfekt läuft, ist dein Code nicht das Problem – der Cloud-“Container” ist einfach zu klein für diese Aufgabe. Um dies zu beheben, ist die effektivste Lösung ein Upgrade auf einen Pro-Plan, der deutlich mehr Speicher bietet (bis zu 1,2 GB). Alternativ könntest du die Dateien nicht direkt zum AI Agent hochladen, sondern dem AI Agent stattdessen einen Web-Link zur Datei bereitstellen, was den speicherintensiven Konvertierungsprozess vollständig umgeht.