Site indisponible : PostgreSQL refuse les nouvelles connexions

Situation critique : L’application affiche too many connections. L’équipe augmente les workers tandis que l’application réessaie sans cesse. La mesure compensatoire peut consommer les dernières connexions disponibles de la base.

Contenir d’abord la vague de connexions

Limitez temporairement la croissance automatique des workers et les tâches non essentielles. Si une version récente a changé le nombre de processus ou la taille des pools, examinez ce changement. Une page de maintenance ou une restriction des entrées du périmètre touché peut donner du temps. Il faut empêcher la pression de se recréer, sans couper inutilement tous les services.

Observer depuis une connexion administrative

Si un emplacement réservé subsiste, un rôle administratif autorisé peut encore se connecter. Une connexion locale ne contourne pas, à elle seule, la limite. Exécutez ces requêtes en lecture seule dans la session administrative PostgreSQL :

SHOW max_connections;

SELECT application_name, usename, state, count(*) AS sessions
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY application_name, usename, state
ORDER BY sessions DESC;

Le résultat aide à repérer les applications ou comptes ayant beaucoup de sessions. Voir les détails des autres sessions exige les droits adaptés. Beaucoup de connexions idle ne prouvent pas une fuite ; un grand pool peut les expliquer. idle in transaction diffère également d’une connexion inactive sans transaction ouverte.

Relier la réponse à la cause

Ramenez les plafonds des pools et le nombre de processus producteurs de connexions au budget partagé de la base. Dans notre cas hypothétique, revenir au réglage précédent des workers peut être plus pertinent qu’augmenter immédiatement max_connections. Ce paramètre exige davantage de ressources et un redémarrage du serveur ; il ne corrige pas automatiquement une fuite ou une tempête de nouvelles tentatives.

Si une requête active identifiée est responsable, envisagez son annulation avec pg_cancel_backend. Cela ne ferme pas nécessairement la session et ne libère pas une connexion inactive. Libérer une session vérifiée peut nécessiter pg_terminate_backend ; sa terminaison peut annuler une transaction ouverte. Identifiez auparavant responsable, conséquences et comportement des nouvelles tentatives. Fermer toutes les sessions sans distinction n’est pas un plan de secours.

Définir la fin de l’incident

Testez une vraie requête applicative, vérifiez la baisse des erreurs et la stabilité du nombre de connexions, puis relancez progressivement les tâches. Si la capacité se remplit vite, la cause reste active. Je recommande ensuite un budget par service, des pools bornés, un responsable et des délais de nouvelle tentative adaptés.

La décision utile : Régler d’abord la production de connexions, plutôt que simplement agrandir le réservoir.

Références techniques: PostgreSQL / Connections · PostgreSQL / Statistics · PostgreSQL / Administration.