Salut à tous
J’exécute n8n avec plusieurs workers, et à mesure que la concurrence augmente, je commence à réfléchir à la gestion des connexions PostgreSQL.
Mon architecture est à peu près :
Load Balancer
↓
Plusieurs workers n8n
↓
PostgreSQL
Ma préoccupation est que si chaque worker ouvre plusieurs connexions à la base de données, la base de données pourrait finalement atteindre sa limite de connexions, ce qui affecterait les performances et la stabilité des workflows.
J’envisage d’utiliser un pooleur de connexions comme PgBouncer, mais j’aimerais comprendre comment d’autres gèrent cela en production.
Pour ceux qui exécutent PostgreSQL avec des déploiements n8n à forte concurrence :
Comment décidez-vous du bon paramètre max_connections ?
Utilisez-vous un pooleur de connexions comme PgBouncer, ou le comportement par défaut de PostgreSQL est-il suffisant ?
Comment surveillez-vous l’épuisement des connexions avant que cela ne devienne un problème ?
Avez-vous trouvé que l’augmentation du nombre de workers ou l’optimisation des requêtes a un impact plus important sur les performances globales de la base de données ?
Décrivez le problème/l’erreur/la question
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Bonjour @Keira_Becky Une bonne approche consiste à optimiser l’utilisation des connexions avant d’augmenter la limite de connexion.
Approche recommandée
Au lieu d’augmenter continuellement max_connections, utilisez un pooler de connexions comme PgBouncer pour réutiliser efficacement les connexions existantes.
n8n Workers
↓
PgBouncer
↓
PostgreSQL
Cela réduit les frais généraux de connexion et aide PostgreSQL à gérer la concurrence plus élevée plus efficacement.
Bonnes pratiques
Utilisez le pooling de connexions pour plusieurs workers
Définissez max_connections en fonction du CPU et de la mémoire de votre serveur
Surveillez les connexions actives, inactives et en attente
Optimisez les requêtes lentes avant d’ajouter plus de workers
Soyez attentif à : Connexions actives
Connexions inactives
Temps d’attente de connexion
Latence des requêtes
Utilisation du CPU et de la mémoire
En production, le pooling de connexions et l’optimisation des requêtes offrent généralement une meilleure scalabilité que l’augmentation simple de la limite de connexion de PostgreSQL.
Dans un déploiement n8n standard, la formule n’est pas simplement workers * 1. Chaque processus worker peut maintenir un pool de connexions.
La Logique de Calcul :
Instance Principale : Nécessite quelques connexions pour l’interface utilisateur, l’API et le planificateur.
Workers : Chaque processus worker maintient généralement un petit pool. Si vous avez 10 workers et que chacun autorise un pool de 10, vous êtes à 100 connexions juste pour les workers.
Surcharge : Postgres alloue de la mémoire pour chaque connexion (environ 2-10 Mo selon work_mem). Définir max_connections trop haut (par exemple, 5000) sans suffisamment de RAM causera au système d’exploitation de tuer Postgres via le OOM killer.
Recommandation : Commencez avec max_connections = 200-500 pour les déploiements de taille moyenne. Si vous dépassez cette limite, ne pas simplement continuer à augmenter le nombre ; passez à un pooler.
PgBouncer est pour les environnements de production à haute concurrence.
Le comportement par défaut de PostgreSQL est « un processus par connexion », ce qui est coûteux. PgBouncer agit comme un proxy léger qui gère un pool de connexions « réelles » à la base de données tout en permettant des milliers de connexions « virtuelles » provenant des workers n8n.
Salut @Keira_Becky
Le levier par processus est DB_POSTGRESDB_POOL_SIZE, qui par défaut vaut 2, donc l’empreinte est approximativement (processus principaux + workers + processeurs de webhooks) multiplié par cette valeur, et vous dimensionnez la base de données autour de ce chiffre au lieu d’estimer à partir du nombre de workers. Augmentez-le par processus uniquement quand les workers attendent réellement sur le pool.
Mettez à l’échelle en exécutant moins de workers avec une concurrence plus élevée plutôt que de nombreux workers avec une faible concurrence. n8n recommande 5 ou plus par worker car un grand nombre de workers à faible concurrence épuise le pool de connexions et provoque des retards et des défaillances :
Cela dépend de votre charge de travail, mais pour la plupart des applications à forte concurrence, le regroupement de transactions est souvent préféré car il permet de réutiliser les connexions de manière plus efficace et supporte un plus grand nombre de clients simultanés.
Le regroupement de sessions peut être un meilleur choix si votre application s’appuie sur des fonctionnalités spécifiques aux sessions, telles que les tables temporaires ou les variables de session, puisque chaque client conserve la même connexion de base de données pendant toute la session.
Avant de choisir un mode, je vous conseille de le tester dans un environnement de staging et de vérifier que vos workflows n8n ne dépendent pas du comportement spécifique aux sessions. Ensuite, surveillez l’utilisation des connexions, la latence des requêtes et le débit global pour confirmer que cela fonctionne comme prévu.
En général, le meilleur choix dépend de la façon dont votre application utilise les connexions de base de données, il vaut donc la peine de le valider avec des charges de travail similaires à celles de la production avant de procéder au déploiement.
