Pool de connexions : PgBouncer
AvancéChaque connexion PostgreSQL est un processus du système : les ouvrir est coûteux et en avoir des milliers ruine les performances.
Le problème#
max_connectionsvaut 100 par défaut. Chaque connexion consomme de la mémoire (plusieurs Mo) et un processus.- Des dizaines d'instances d'application × un pool de 20 connexions chacune = des centaines de connexions, pour la plupart inactives.
La solution : un pooleur externe#
PgBouncer (ou pgcat, Odyssey, ou le proxy intégré à votre hébergeur) maintient un petit nombre de connexions réelles et en prête aux clients à la demande.
| Mode | Une connexion serveur est affectée… | Limites |
|---|---|---|
| Session | Pour toute la durée de la connexion client | Peu de mutualisation |
| Transaction (le plus courant) | Le temps d'une transaction | Pas d'état de session entre transactions (SET, verrous consultatifs de session, LISTEN, tables temporaires) |
| Statement | Le temps d'une instruction | Interdit les transactions multi-instructions |
Dimensionner#
Un bon ordre de grandeur pour le nombre de connexions actives vers la base : de l'ordre de 2 × nombre de coeurs CPU à quelques fois ce nombre. Au-delà, les requêtes se disputent le processeur au lieu d'avancer.
Piège : en mode transaction, les fonctionnalités liées à la session (requêtes préparées côté serveur selon la version du pooleur,
SET LOCALhors transaction,pg_advisory_lockde session) se comportent mal. Vérifiez la compatibilité de votre pilote avec le mode choisi.