SQL Academy · Leçon

Mise en commun des connexions : PgBouncer

Exécutez PgBouncer en mode de mise en commun par transaction, dimensionnez correctement les ensembles de connexions et évitez le piège des instructions préparées.

Mise en commun des connexions : PgBouncer est une leçon SQL Academy gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage SQL Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Academy comprend 4 leçons au total.

Pourquoi regrouper les connexions ?

Chaque connexion PostgreSQL est un processus OS distinct, qui consomme beaucoup de mémoire et de CPU. Les applications qui ouvrent et ferment une connexion pour chaque requête épuisent rapidement le serveur. La mise en pool réutilise un petit ensemble de connexions persistantes.

Coût par connexion

Un processus serveur PostgreSQL classique utilise 5 à 10 MB de RAM. 500 connexions représentent environ 5 GB de RAM uniquement pour les processus serveur. PgBouncer peut multiplexer des milliers de clients sur 50 connexions serveur.

Trois modes de mise en pool

Session — le client obtient une connexion dédiée pendant toute la session
Transaction — le client obtient une connexion par transaction
Instruction — une connexion par instruction (rarement utilisé)

Mode transactionnel (recommandé)

Chaque transaction obtient une connexion serveur. Le même client peut utiliser des connexions différentes d’une transaction à l’autre.

# pgbouncer.ini
[databases]
mydb = host=primary port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction
listen_port = 6432
max_client_conn = 1000
default_pool_size = 50

Limites du mode transactionnel

Les fonctionnalités qui nécessitent un état de session ne fonctionnent plus :

Instructions préparées (elles nécessitent le même processus serveur entre les appels)
SET LOCAL ... (la portée par transaction convient ; SET ... qui persiste entre les transactions ne convient pas)
LISTEN / NOTIFY (nécessitent une connexion persistante)
Curseurs qui restent actifs après une transaction

Mode session

Utilisez-le lorsque le mode transactionnel empêche votre application de fonctionner, mais vous aurez moins de clients simultanés.

Dimensionner les pools

Règle générale : default_pool_size ≈ vCPU count × 2 + spindles. Une valeur trop élevée provoque des changements de contexte qui réduisent le débit ; une valeur trop faible fait attendre les clients dans le pool.

PgBouncer devant HAProxy

Architecture de production typique :

App → HAProxy (read/write routing) → PgBouncer (pooling) → Postgres

Instructions préparées en mode transactionnel

Les versions récentes de PgBouncer (1.21 et ultérieures) prennent en charge les instructions préparées au niveau du protocole en mode transactionnel. Avec les versions plus anciennes, utilisez des requêtes simples ou le mode session.

Surveiller PgBouncer

Connectez-vous à la base de données d’administration (base spéciale) :

psql -p 6432 -U pgbouncer pgbouncer

-- Commands:
SHOW STATS;
SHOW POOLS;
SHOW CLIENTS;
SHOW SERVERS;

Alternatives

pgpool-II — mise en pool, équilibrage de charge et réécriture des requêtes
Odyssey — gestionnaire de connexions de Yandex, multithread
Ensembles de connexions côté pilote — généralement combinés à PgBouncer pour une mise en pool à l’échelle du cluster

Pool de l’application et PgBouncer

Les applications utilisent généralement leur propre pool de connexions (HikariCP, pgxpool) AND passent par PgBouncer. Il s’agit d’une mise en pool à deux niveaux : le pool de l’application conserve les connexions vers le gestionnaire ; celui-ci les multiplexe sur PostgreSQL.

Récapitulatif

PgBouncer est indispensable dès que l’échelle n’est plus triviale.

Le mode transactionnel est la norme
Surveillez les instructions préparées, SET et LISTEN
Taille du pool : environ vCPU × 2
Surveillez avec SHOW POOLS

Vérification rapide

Quel mode PgBouncer multiplexe le plus grand nombre de clients sur le plus petit nombre de connexions serveur ?

Questions Fréquemment Posées

La leçon « Mise en commun des connexions : PgBouncer » est-elle gratuite ?

Oui — le texte complet de « Mise en commun des connexions : PgBouncer » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours SQL Academy, passe à CoddyKit PRO. Le cours SQL Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Mise en commun des connexions : PgBouncer » ?

Exécutez PgBouncer en mode de mise en commun par transaction, dimensionnez correctement les ensembles de connexions et évitez le piège des instructions préparées. Tu pratiques SQL Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer SQL Academy ?

Aucune expérience préalable n'est requise. SQL Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Mise en commun des connexions : PgBouncer » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon SQL Academy ?

Oui. Chaque leçon SQL Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

pg_stat_statements : requêtes principales
pgBadger pour analyser les journaux
Mise en commun des connexions : PgBouncer
Planification de capacité et audits du gonflement

← Retour à SQL Academy