Pooling delle connessioni: PgBouncer
Esegua PgBouncer in modalità transaction pooling, dimensioni correttamente i pool ed eviti il problema delle prepared statement.
Pooling delle connessioni: PgBouncer è una lezione SQL Academy gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento SQL Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso SQL Academy include 4 lezioni in totale.
Perché usare un pool di connessioni?
Ogni connessione a Postgres è un processo del sistema operativo distinto e consuma molta memoria e CPU. Le applicazioni che aprono e chiudono connessioni per ogni richiesta esauriscono rapidamente le risorse del server. Il pooling riutilizza un piccolo insieme di connessioni di lunga durata.
Costo per connessione
Un backend Postgres tipico usa 5–10 MB di RAM. 500 connessioni equivalgono a circa 5 GB di RAM solo per i backend. PgBouncer può multiplexare migliaia di client su 50 connessioni backend.
Tre modalità di pooling
- Sessione — il client riceve una connessione dedicata per l'intera sessione
- Transazione — il client riceve una connessione per ogni transazione
- Istruzione — una connessione per ogni istruzione (usata raramente)
Modalità transazione (consigliata)
Ogni transazione riceve una connessione al server. Lo stesso client può usare connessioni diverse tra una transazione e l'altra.
# pgbouncer.ini
[databases]
mydb = host=primary port=5432 dbname=mydb
[pgbouncer]
pool_mode = transaction
listen_port = 6432
max_client_conn = 1000
default_pool_size = 50Limiti della modalità transazione
Le funzionalità che richiedono lo stato della sessione non funzionano:
- Prepared statement (richiedono lo stesso backend tra una chiamata e l'altra)
- SET LOCAL ... (per transazione va bene; SET ... persistente tra le transazioni no)
- LISTEN / NOTIFY (richiedono una connessione persistente)
- Cursori che rimangono attivi oltre la durata di una transazione
Modalità sessione
La usi quando la modalità transazione crea problemi all'applicazione, tenendo presente che potrà gestire meno client contemporaneamente.
Dimensionare i pool
Regola pratica: default_pool_size ≈ vCPU count × 2 + spindles. Un valore troppo alto fa crollare il throughput a causa dei cambi di contesto; uno troppo basso fa attendere il pool.
PgBouncer davanti a HAProxy
Stack di produzione tipico:
App → HAProxy (read/write routing) → PgBouncer (pooling) → Postgres
Prepared statement nella modalità transazione
Le versioni recenti di PgBouncer (1.21+) supportano i prepared statement a livello di protocollo nella modalità transazione. Nelle versioni precedenti: usi query semplici o la modalità sessione.
Monitorare PgBouncer
Si connetta al database amministrativo (database speciale):
psql -p 6432 -U pgbouncer pgbouncer
-- Commands:
SHOW STATS;
SHOW POOLS;
SHOW CLIENTS;
SHOW SERVERS;Alternative
- pgpool-II — pooling + bilanciamento del carico + riscrittura delle query
- Odyssey — pooler di Yandex, multi-thread
- Pool lato driver — generalmente combinati con PgBouncer per il pooling a livello di cluster
Pool dell'applicazione + PgBouncer
Le applicazioni in genere usano un proprio pool di connessioni (HikariCP, pgxpool) E passano attraverso PgBouncer. È un pooling a due livelli: il pool dell'applicazione mantiene le connessioni verso il bouncer, che le multiplexa sulle connessioni a Postgres.
Riepilogo
PgBouncer è essenziale a qualsiasi scala non banale.
- La modalità transazione è lo standard
- Faccia attenzione a prepared statement / SET / LISTEN
- Dimensione del pool circa vCPU × 2
- Monitori con SHOW POOLS
Verifica rapida
Quale modalità di PgBouncer multiplexa il maggior numero di client con il minor numero di connessioni al server?
Domande Frequenti
La lezione «Pooling delle connessioni: PgBouncer» è gratuita?
Sì — il testo completo di «Pooling delle connessioni: PgBouncer» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso SQL Academy, passa a CoddyKit PRO. Il corso SQL Academy include 4 lezioni in totale.
Cosa imparerò in «Pooling delle connessioni: PgBouncer»?
Esegua PgBouncer in modalità transaction pooling, dimensioni correttamente i pool ed eviti il problema delle prepared statement. Eserciti SQL Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare SQL Academy?
Non è richiesta alcuna esperienza precedente. SQL Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.
Quanto tempo richiede la lezione «Pooling delle connessioni: PgBouncer»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione SQL Academy?
Sì. Ogni lezione SQL Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- pg_stat_statements: query principali
- pgBadger per l’analisi dei log
- Pooling delle connessioni: PgBouncer
- Pianificazione della capacità e audit del bloat