GCP : délai d'expiration de la connexion Postgres lors du démarrage de n8n sur Cloud Run (socket Unix Cloud SQL)

Questions
1

Description
Nous avons observé un incident de démarrage ponctuel dans n8n sur Google Cloud Run avec PostgreSQL sur Cloud SQL (connexion par socket Unix).

Environnement

  • Version de n8n : 2.32.5
  • Runtime : Google Cloud Run (Gen2)
  • Région : europe-west3
  • Base de données : PostgreSQL sur Cloud SQL
  • Méthode de connexion : Socket Unix sous /cloudsql

Ce qui s’est passé

  • Lors d’une fenêtre de démarrage, n8n a enregistré à plusieurs reprises :
    • Error: timeout exceeded when trying to connect
    • des traces de pile pointant vers les chemins d’acquisition de connexion pg-pool, @n8n/typeorm et @n8n/db.
  • Durant cette même fenêtre :
    • le point de terminaison racine a pu retourner 200
    • certains appels API ont retourné 500 / latence élevée
    • les tâches de fond dépendantes de la base de données ont signalé des défaillances
  • Un redéploiement manuel a été effectué.
  • Peu de temps après le redéploiement, le service s’est stabilisé et fonctionne normalement depuis.
2

Salut @rgrzesk, en attendant une réponse, voici quelques ressources qui pourraient t’aider :

Ressources suggérées

Automatiquement associées à ta question.

Documentation :

Forum :

@Mayank1024, @Websensepro, @tamy.santos - vous avez aidé avec des problèmes similaires avant, pouvez-vous jeter un coup d’œil ?

Suggéré automatiquement par le bot communautaire de n8n. C’est un projet pilote - partage tes retours ici.

3

Salut @rgrzesk Il semble que tu signales juste un bug, c’est ça ? Ton instance va bien maintenant ?

4

@rgrzesk

Cela ressemble plus à un rapport d’incident pour moi.
Vous voudriez peut-être signaler le problème à votre fournisseur

5

Bonjour @rgrzesk
« timeout exceeded when trying to connect » provient du délai d’attente d’acquisition de pg-pool, donc le pool n’a jamais fourni de client dans DB_POSTGRESDB_CONNECTION_TIMEOUT, plutôt que la socket Cloud SQL soit inaccessible. DB_POSTGRESDB_POOL_SIZE par défaut à 2, et sur une seule instance Cloud Run, les requêtes de démarrage plus le trafic entrant font la queue derrière ces deux connexions, c’est pourquoi le point de terminaison racine est resté 200 tandis que les appels soutenus par la base de données sont passés à 500. Augmentez les deux sur la révision :

DB_POSTGRESDB_POOL_SIZE=10
DB_POSTGRESDB_CONNECTION_TIMEOUT=60000

Puis plaquez la concurrence du conteneur Cloud Run à à peu près ce que le pool peut servir (10 à 20), pour qu’une rafale ne puisse pas le dépasser à nouveau. Cloud Run permet 100 connexions par instance à Cloud SQL, donc 10 reste bien en deçà de cela.

6

Je suis content que le service s’est stabilisé et fonctionne normalement depuis :slight_smile:

7

Merci ! Je vais configurer CloudRun de cette façon.
Cependant, ce qui m’inquiète — c’est arrivé tout d’un coup et l’instance fonctionne depuis 6 mois, sans aucun problème jusqu’à présent.

8

Un délai d’expiration d’acquisition pg-pool vous indique qu’aucun client n’est devenu disponible avant l’échéance. Cela ne prouve pas que le pool était trop petit. Parce que cela s’est produit une fois après six mois stables, augmenter le pool peut seulement déplacer la pression vers Cloud SQL.

Alignez la révision affectée avec le graphique de connexion Cloud SQL et le journal de démarrage Cloud Run pour cet horodatage. Si les deux connexions existantes étaient occupées tandis que les requêtes étaient en file d’attente, un pool plus grand ou une concurrence de conteneur plus faible est raisonnable. Si les nouvelles connexions expiraient, la taille du pool n’est pas la cause première.

Modifiez une limite à la fois et gardez la valeur précédente enregistrée. Sinon, l’incident suivant ne vous indiquera pas quel changement a aidé.