Hi zusammen,
ich betreibe n8n mit mehreren Workern, und mit zunehmender Parallelität fange ich an, über die PostgreSQL-Verbindungsverwaltung nachzudenken.
Meine Architektur sieht ungefähr so aus:
Load Balancer
↓
Mehrere n8n Worker
↓
PostgreSQL
Meine Sorge ist, dass wenn jeder Worker mehrere Datenbankverbindungen öffnet, die Datenbank irgendwann an ihr Verbindungslimit stoßen könnte, was die Workflow-Leistung und Stabilität beeinträchtigt.
Ich erwäge, einen Connection Pooler wie PgBouncer zu verwenden, möchte aber gerne verstehen, wie andere das in der Produktion handhaben.
Für diejenigen, die PostgreSQL mit n8n-Deployments hoher Parallelität betreiben:
Wie entscheidet ihr euch für die richtige max_connections-Einstellung?
Verwendet ihr einen Connection Pooler wie PgBouncer, oder ist das Standardverhalten von PostgreSQL ausreichend?
Wie überwacht ihr auf Verbindungserschöpfung, bevor sie zum Problem wird?
Habt ihr festgestellt, dass die Erhöhung der Worker-Anzahl oder die Optimierung von Abfragen einen größeren Einfluss auf die gesamte Datenbankleistung hat?
Beschreiben Sie das Problem/den Fehler/die Frage
Welche Fehlermeldung wird angezeigt (falls vorhanden)?
Bitte teilen Sie Ihren Workflow
(Wählen Sie die Knoten auf Ihrer Canvas aus und verwenden Sie die Tastaturkürzel CMD+C/STRG+C und CMD+V/STRG+V zum Kopieren und Einfügen des Workflows.)
Teilen Sie die vom letzten Knoten zurückgegebene Ausgabe mit
Hallo @Keira_Becky Ein guter Ansatz besteht darin, die Verbindungsauslastung zu optimieren, bevor Sie das Verbindungslimit erhöhen.
Empfohlener Ansatz
Anstatt max_connections kontinuierlich zu erhöhen, verwenden Sie einen Connection Pooler wie PgBouncer, um vorhandene Verbindungen effizient wiederzuverwenden.
n8n Workers
↓
PgBouncer
↓
PostgreSQL
Dies reduziert den Verbindungs-Overhead und hilft PostgreSQL, höhere Parallelität effizienter zu bewältigen.
Best Practices
Verwenden Sie Connection Pooling für mehrere Worker
Legen Sie max_connections basierend auf CPU und Speicher Ihres Servers fest
Überwachen Sie aktive, untätige und wartende Verbindungen
Optimieren Sie langsame Abfragen, bevor Sie weitere Worker hinzufügen
In der Produktion bieten Connection Pooling und Abfrageoptimierung in der Regel bessere Skalierbarkeit als einfach nur das Verbindungslimit von PostgreSQL zu erhöhen.
In einer Standard-n8n-Bereitstellung ist die Formel nicht einfach workers * 1. Jeder Worker-Prozess kann einen eigenen Verbindungspool verwalten.
Die Berechnungslogik:
Hauptinstanz: Benötigt einige Verbindungen für die UI, API und den Scheduler.
Worker: Jeder Worker-Prozess verwaltet typischerweise einen kleinen Pool. Wenn du 10 Worker hast und jeder einen Pool von 10 erlaubt, bist du bereits bei 100 Verbindungen nur für die Worker.
Overhead: PostgreSQL reserviert Speicher für jede Verbindung (etwa 2–10 MB je nach work_mem). Wenn du max_connections zu hoch setzt (z. B. 5000) ohne ausreichend RAM, wird das Betriebssystem PostgreSQL durch den OOM-Killer beenden.
Empfehlung: Beginne mit max_connections = 200–500 für mittlere Bereitstellungen. Wenn du diesen Wert überschreitest, erhöhe die Zahl nicht einfach weiter; nutze stattdessen einen Pooler.
PgBouncer ist für Produktionsumgebungen mit hoher Concurrency gedacht.
Das Standardverhalten von PostgreSQL ist „ein Prozess pro Verbindung,
Hi @Keira_Becky
Der Pro-Prozess-Hebel ist DB_POSTGRESDB_POOL_SIZE, der standardmäßig auf 2 eingestellt ist. Der Speicherbedarf ist daher ungefähr (Hauptprozesse + Worker + Webhook-Prozessoren) mal dieser Wert, und du dimensionierst die Datenbank nach dieser Zahl, anstatt sie nach der Worker-Anzahl zu schätzen. Erhöhe ihn pro Prozess nur, wenn Worker tatsächlich auf den Pool warten.
Skaliere, indem du weniger Worker mit höherer Parallelität laufen lässt, anstatt viele Worker mit niedriger Parallelität zu verwenden. n8n empfiehlt 5 oder höher pro Worker, da eine große Anzahl von Workern mit niedriger Parallelität den Verbindungspool erschöpft und zu Verzögerungen und Ausfällen führt:
Verwendest du PgBouncer bei n8n im Transaction Mode oder Session Mode? Falls du beide ausprobiert hast, welche Unterschiede hast du in der Produktion bemerkt?
Das hängt von deiner Workload ab, aber für die meisten High-Concurrency-Anwendungen wird Transaction Pooling oft bevorzugt, da es ermöglicht, Verbindungen effizienter zu nutzen und eine größere Anzahl von gleichzeitigen Clients zu unterstützen.
Session Pooling kann die bessere Wahl sein, wenn deine Anwendung auf sessionsspezifische Funktionen angewiesen ist, wie beispielsweise temporäre Tabellen oder Sessionsvariablen, da jeder Client die gleiche Datenbankverbindung für die gesamte Session behält.
Bevor du dich für einen Modus entscheidest, würde ich ihn in einer Staging-Umgebung testen und überprüfen, dass deine n8n-Workflows nicht von sessionsspezifischem Verhalten abhängen. Überwache dann die Verbindungsnutzung, die Abfragelatenz und den Gesamtdurchsatz, um zu bestätigen, dass alles wie erwartet funktioniert.
Allgemein hängt die beste Wahl davon ab, wie deine Anwendung Datenbankverbindungen nutzt, daher lohnt es sich, es mit produktionsähnlichen Workloads zu validieren, bevor du es einsetzt.