« Too many connections » dans Postgres : ce qui retient les connexions, et comment dimensionner le bassin.

On appelle « trop de connexions » deux choses différentes. Soit le serveur de base de données n’a plus de places, soit le bassin de votre appli n’a plus de connexion libre et une requête a cessé d’attendre. Les correctifs diffèrent : lisez d’abord le texte exact.

Connectez-vous avec psql et regardez avant de changer quoi que ce soit. pg_stat_activity contient une ligne par connexion. Une ligne à l’état idle est une connexion qui dort dans un bassin. idle in transaction est pire : une transaction a été ouverte sans jamais être validée, et elle retient aussi des verrous.

• Beaucoup de lignes `idle` pour un même `application_name` : un bassin trop grand, ou un processus qui crée un bassin à chaque requête. Plafonnez le bassin (plus bas) et créez-le une seule fois au démarrage.
• Des lignes de processus oubliés : un ancien déploiement, un aperçu, un processus de tâches, un carnet Jupyter, un outil de BI resté ouvert. Chacun garde son propre bassin.
• `idle in transaction` pendant des minutes : un chemin de code qui ouvre une transaction et sort trop tôt, ou un débogueur arrêté en pleine requête. Corrigez le code, et réglez idle_in_transaction_session_timeout pour que Postgres y mette fin lui-même.
• Beaucoup de lignes `active`, toutes lentes : les connexions travaillent, elles ne fuient pas. Plus de connexions n’aideront pas; des requêtes plus rapides, oui. Voir trouver les requêtes lentes.

-- Who holds connections to this database, and doing what
SELECT usename, application_name, state, count(*) AS conns,
       max(now() - state_change) AS longest_in_state
FROM pg_stat_activity
WHERE datname = current_database()
  AND backend_type = 'client backend'
GROUP BY 1, 2, 3
ORDER BY conns DESC;

-- Sessions stuck inside an open transaction
SELECT pid, usename, application_name, now() - state_change AS stuck_for, left(query, 80) AS last_query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY stuck_for DESC;

Chaque processus qui parle à la base garde son propre bassin, et toutes ses connexions peuvent être ouvertes en même temps. Le nombre qui doit tenir sous la limite du serveur est la somme de tous les processus :

(processus web × connexions par processus) + (processus de tâches × connexions par processus) + commande de mise en production ou migrations + tout le reste qui se connecte (aperçus, `psql`, outils de BI)

Une connexion par fil suffit. Un processus Puma à 3 fils n’a jamais besoin de plus de 3 connexions pour les requêtes. Donnez-lui-en plus et elles dorment. Donnez-lui-en moins et les fils font la file, d’où l’expiration de Rails plus haut.

# Rails (config/database.yml). Rails 8.1 also accepts max_connections:
production:
  url: <%= ENV["DATABASE_URL"] %>
  pool: <%= ENV.fetch("DB_POOL", 6) %>   # 3 Puma threads + 3 job threads

// Node (pg): one Pool per process, created once at startup
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL, max: 8 });

# Django: persistent connections, one per worker thread
DATABASES["default"]["CONN_MAX_AGE"] = 600

# SQLAlchemy: cap the overflow too, or 5 becomes 15
engine = create_engine(url, pool_size=5, max_overflow=2)

Une base Canner accepte jusqu’à 20 connexions en même temps (documentation des tâches en arrière-plan). Un projet exécute un seul processus, donc le budget se calcule facilement. Un projet worker distinct branché sur la même base compte dans les mêmes 20 :

• Rails avec GoodJob dans le processus web : 3 fils Puma + 3 fils de tâches + 3 pour l’écoute et l’entretien de GoodJob = 9. L’exemple de la documentation fixe DB_POOL à 12, ce qui laisse 8.
• Node avec un seul `pg.Pool` : le max par défaut de 10 prend la moitié du budget. Un déploiement d’aperçu de la même appli est un autre processus, avec le même DATABASE_URL et 10 de plus. Réglez max: 8 et les deux entrent, avec de la place pour psql.
• Prisma 6 : la valeur par défaut dépend du nombre de processeurs que voit le processus, pas de votre forfait. Sur un hôte à 8 cœurs physiques, ça donne 17. Fixez connection_limit vous-même.
• La commande de mise en production : les migrations roulent pendant que la version actuelle sert encore; gardez une ou deux connexions de marge.

Chaque connexion Postgres est un processus serveur distinct, avec sa propre mémoire. Une fois le processeur et le disque occupés, plus de connexions n’ajoutent que de la contention. La règle empirique du wiki de PostgreSQL pour les connexions actives est (core_count × 2) + effective_spindle_count, un chiffre bien plus petit que ce qu’on imagine.

max_connections exige aussi un redémarrage du serveur. Sur une base gérée, on ne peut généralement pas le régler : le fournisseur le dimensionne selon la mémoire. Si vous êtes à la limite à cause de connexions inactives, des bassins plus petits règlent le problème gratuitement.

Un regroupeur de connexions se place entre l’appli et Postgres et distribue les connexions serveur. Ce qu’il peut partager dépend du mode. En mode session (le mode par défaut de PgBouncer), un client garde une connexion serveur jusqu’à ce qu’il se déconnecte. Rien ne casse, et rien n’est partagé : 20 clients ouverts exigent encore 20 connexions serveur. En mode transaction, la connexion serveur retourne au bassin à la fin de chaque transaction; des centaines de clients surtout inactifs peuvent alors se partager quelques connexions. Le prix : tout ce qui dépend d’une session cesse de fonctionner.

• Prenez le mode transaction quand beaucoup de processus éphémères ou sans serveur ouvrent chacun des connexions. Désactivez alors ce qui dépend d’une session : DISABLE_SERVER_SIDE_CURSORS = True dans Django, pgbouncer=true sur l’URL regroupée de Prisma avec une URL directe pour les migrations, et advisory_locks: false pour les migrations Rails.
• Restez en mode session pour un ou quelques processus de longue durée, et pour tout ce qui repose sur LISTEN/NOTIFY ou les verrous consultatifs : GoodJob, verrous de migration, files de tâches dans Postgres.

Canner exécute un processus par projet et permet jusqu’à 20 connexions par base, partagées avec tout projet worker distinct qui s’y branche. Ça convient à une appli web dont les tâches roulent dans le même processus. Si votre architecture a besoin de dizaines d’instances distinctes ou de fonctions sans serveur qui parlent à la même base en même temps, il vous faut un regroupeur en mode transaction devant un serveur dimensionné pour ça, et Canner ne l’offre pas aujourd’hui.