n8n davon abhalten, PostgreSQL zu überlasten, wenn Workflow-Ausführungen plötzlich zunehmen

Fragen
1

Ich führe mehrere n8n-Workflows aus, die PostgreSQL lesen und aktualisieren. Bei Verkehrsspitzen starten viele Ausführungen gleichzeitig und PostgreSQL zeigt hohe CPU-Auslastung und zu viele aktive Verbindungen.
Ich führe derzeit Abfragen wie folgt durch: SELECT id, status
FROM orders
WHERE status = ‘pending’
ORDER BY created_at
LIMIT 100;
Ich erwäge, die n8n-Parallelität zu begrenzen und Indizes hinzuzufügen: CREATE INDEX orders_pending_idx
ON orders (status, created_at);
Würden Sie n8n-Parallelitätsbeschränkungen, bessere Indizes, Connection Pooling, Batching oder eine Kombination dieser Maßnahmen priorisieren?

Problem/Fehler/Frage beschreiben

Wie lautet die Fehlermeldung (falls vorhanden)?

Bitte teilen Sie Ihren Workflow mit

(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.)

Ausgabe des letzten Knotens teilen

Informationen zu Ihrer n8n-Einrichtung

  • n8n-Version:
  • Datenbank (Standard: SQLite):
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main):
  • n8n wird ausgeführt über (Docker, npm, n8n cloud, Desktop-App):
  • Betriebssystem:
2

Hey @Decoure_Ryan, während du auf eine Antwort wartest, könnten dir diese Ressourcen helfen:

Empfohlene Ressourcen

Automatisch zu deiner Frage zugeordnet.

Dokumentation:

Forum:

@anon45958619, @zenithflare, @Websensepro - ihr habt bei ähnlichen Problemen schon geholfen, könnt ihr da mal schauen?

Automatisch vorgeschlagen vom Community-Bot von n8n. Es ist ein Pilotprojekt – bitte teilt euer Feedback hier mit.

3

Hi @Decoure_Ryan ich würde das mit einer Kombination aus n8n-Concurrency-Kontrolle, ordentlicher PostgreSQL-Indexierung, Batching und Connection Pooling handhaben.

Das Wichtigste ist, n8n nicht mehr Arbeit an PostgreSQL schicken zu lassen, als die Datenbank komfortabel verarbeiten kann

n8n-Concurrency kontrollieren

Wenn hunderte Workflows auf einmal starten, kann PostgreSQL schnell überlastet werden. Setzen Sie ein vernünftiges Concurrency-Limit und erhöhen Sie es schrittweise, während Sie die Performance überwachen.

Machen Sie die Abfrage effizienter

Ihr Index ist ein guter Anfang:

CREATE INDEX orders_pending_idx
ON orders (status, created_at);

Das hilft PostgreSQL, ausstehende Bestellungen viel schneller zu finden.

Verwenden Sie kleinere Batches

Statt tausende Datensätze auf einmal zu ziehen:

SELECT id, status
FROM orders
WHERE status = ‘pending’
ORDER BY created_at
LIMIT 100;

Verarbeiten Sie einen überschaubaren Batch, dann laden Sie den nächsten.

Verwenden Sie Connection Pooling

Wenn Sie viele gleichzeitige n8n-Ausführungen haben, hilft Connection Pooling zu verhindern, dass PostgreSQL mit Verbindungen überflutet wird.

4

Hi @Decoure_Ryan

Um deine unmittelbaren Leistungsprobleme zu beheben, solltest du vorrangig einen zusammengesetzten Index auf (status, created_at) hinzufügen. Deine aktuelle Abfrage löst wahrscheinlich einen vollständigen Tabellenscan aus, der CPU-Spitzen verursacht, wenn die Tabelle wächst. Durch die Implementierung dieses Index kann PostgreSQL „pending

5

Hallo @Decoure_Ryan

Zusätzlich dazu

Prioritisiere die Fixes in dieser Reihenfolge:

  1. Verwende SKIP LOCKED und einen partiellen Index:

    SELECT id, status
FROM orders
WHERE status = 'pending'
ORDER BY created_at
LIMIT 100
FOR UPDATE SKIP LOCKED;


    CREATE INDEX orders_pending_idx 
ON orders (created_at) 
WHERE status = 'pending';

  2. Verbindungs-Pooling hinzufügen:
    Setze PgBouncer (im Transaktionsmodus) vor PostgreSQL oder begrenzte die Verbindungs-Pool-Größe von n8n (DB_POSTGRESDB_POOL_SIZE=10).

  3. Drossle die Ausführungs-Nebenläufigkeit:
    Wenn du Queue Mode (Redis) verwendest, setze N8N_CONCURRENCY_PRODUCTION_LIMIT=10 auf deinen Workern. Wenn auf einer einzelnen Instanz, verarbeite Datensätze sequenziell in Batches statt dutzende parallele Ausführungen zu starten.

Hoffentlich hilft das weiter.

6

Hi @Decoure_Ryan
Wenn n8n seine eigenen Daten in derselben Postgres-Instanz speichert, ist ein Teil des Spitzenwerts n8n, das über sich selbst schreibt. Jede Produktionsausführung fügt eine Zeile in execution_entity und die gesamte Lauf-Payload in execution_data ein, und dieses Schreibvolumen folgt der Ausführungsanzahl, unabhängig davon, wie die Orders-Abfrage optimiert wird. Überprüfe mit SELECT pg_size_pretty(pg_total_relation_size('execution_data')); und wenn diese Tabelle dominiert, höre auf, erfolgreiche Läufe zu speichern, und verkürze die Aufbewahrung:

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_MAX_AGE=72