GCP: Postgres-Verbindungszeitüberschreitung beim n8n-Start auf Cloud Run (Cloud SQL Unix Socket)

Fragen
1

Beschreibung
Wir beobachteten einen einmaligen Startup-Incident in n8n auf Google Cloud Run mit PostgreSQL auf Cloud SQL (Unix-Socket-Verbindung).

Umgebung

  • n8n-Version: 2.32.5
  • Runtime: Google Cloud Run (Gen2)
  • Region: europe-west3
  • Datenbank: PostgreSQL auf Cloud SQL
  • Verbindungsmethode: Unix-Socket unter /cloudsql

Was ist passiert

  • Während eines Startup-Fensters protokollierte n8n wiederholt:
    • Error: timeout exceeded when trying to connect
    • Stack Traces, die auf pg-pool, @n8n/typeorm und @n8n/db Verbindungsakquisitionspfade hinweisen.
  • In demselben Fenster:
    • Root-Endpunkt konnte 200 zurückgeben
    • Einige API-Aufrufe gaben 500 / hohe Latenz zurück
    • Datenbankabhängige Hintergrundaufgaben meldeten Fehler
  • Eine manuelle Neubereitstellung wurde durchgeführt.
  • Kurz nach der Neubereitstellung stabilisierte sich der Dienst und funktioniert seitdem normal.
2

Hallo @rgrzesk, während du auf eine Antwort wartest, findest du hier ein paar Dinge, die dir helfen könnten:

Empfohlene Ressourcen

Automatisch zu deiner Frage zugeordnet.

Dokumentation:

Forum:

@Mayank1024, @Websensepro, @tamy.santos – ihr habt schon bei ähnlichen Problemen geholfen, könntet ihr das mal anschauen?

Automatisch vorgeschlagen durch n8ns Community-Bot. Es ist ein Pilotprojekt – teilt bitte hier euer Feedback.

3

Hallo @rgrzesk, es sieht so aus, als würdest du nur einen Bug melden, stimmt’s? Deine Instanz läuft jetzt wieder einwandfrei?

4

@rgrzesk

Das sieht für mich mehr wie ein Incident Report aus.
Vielleicht möchtest du das Problem mit deinem Anbieter besprechen

5

Hi @rgrzesk
„timeout exceeded when trying to connect

6

Ich freue mich, dass sich der Dienst stabilisiert hat und seitdem normal funktioniert :slight_smile:

7

Danke! Ich werde CloudRun auf diese Weise optimieren.
Allerdings macht mir Sorgen – es ist plötzlich passiert und die Instanz läuft seit 6 Monaten, bisher ohne Probleme.

8

Ein pg-pool-Acquisition-Timeout teilt dir mit, dass kein Client vor der Frist verfügbar wurde. Es beweist jedoch nicht, dass der Pool zu klein war. Da dies nach sechs stabilen Monaten einmal vorkam, kann eine Vergrößerung des Pools den Druck nur zu Cloud SQL verlagern.

Vergleiche die betroffene Revision mit dem Cloud SQL-Verbindungsgraph und dem Cloud Run-Startprotokoll für diesen Zeitstempel. Wenn beide vorhandenen Verbindungen beschäftigt waren, während Anfragen in der Warteschlange standen, ist ein größerer Pool oder eine niedrigere Container-Concurrency angemessen. Wenn neue Verbindungen ein Timeout aufwiesen, ist die Pool-Größe nicht die Grundursache.

Ändere jeweils eine Grenze und halte den vorherigen Wert fest. Ansonsten wird dir beim nächsten Incident nicht klar sein, welche Änderung geholfen hat.