Calcolatore del pool di connessioni

Dimensionare un pool di connessioni per il rilascio, non per la media

I pool di connessioni raramente cedono a carico costante. Cedono durante un rilascio, quando i vecchi pod non si sono ancora spenti e i nuovi hanno già aperto i loro pool, e la domanda raddoppia per un momento. Questo strumento calcola quanto la tua flotta chiede davvero al database, a riposo e in quell'istante, e confronta entrambi con il limite che l'istanza applica.

Come funziona

• Moltiplica le istanze applicative per la dimensione del pool: è il numero che vede il database, non la dimensione che hai configurato.
• Sottrae le connessioni riservate a replica e monitoraggio, così confronti con ciò che è davvero disponibile.
• Raddoppia la domanda per modellare un rilascio progressivo, quando istanze vecchie e nuove tengono pool contemporaneamente.
• Segnala tre stati: oltre il limite, così stretto che un rilascio lo sfonderebbe, e comodo.

utilizzabili   = max_connections - riservate
a_regime       = istanze x pool_per_istanza
durante_rilascio = a_regime x 2

sicuro quando durante_rilascio <= utilizzabili

Esempio pratico

Un servizio su 40 pod, ciascuno con un pool di 20, contro un'istanza da 500 connessioni che ne riserva 15.

1. utilizzabili = 500 - 15 = 485
2. a regime = 40 x 20 = 800 — già il 165% del limite
3. margine = 485 - 800 = -315, quindi le connessioni vengono già rifiutate adesso
4. dimezzando il pool a 10: a regime = 400, cioè 82% — a riposo ci sta
5. ma durante un rilascio: 400 x 2 = 800, ancora 165%, quindi i rilasci continuano a rompersi
6. pool di 6: a regime = 240 (49%), rilascio = 480 contro 485 — ci sta per un soffio

Il pool che sopravvive a un rilascio è un terzo di quello che sopravvive soltanto alla media. Tra il passo due e il passo sei nel traffico non è cambiato nulla — solo l'impostazione del pool e la disponibilità a dimensionarlo sul momento peggiore anziché su quello tipico.

Come leggere il risultato

• Un pool di 6 per pod sembra piccolo, e non lo è. La guida di HikariCP sostiene che i pool piccoli battono quelli grandi: a un pool bastano le connessioni necessarie a tenere occupati i core del database, e attendere un attimo nell'applicazione costa meno che attendere dentro il database. L'obiettivo sono poche connessioni per core sull'intera flotta.
• Moltiplica per ogni processo che apre un pool, non solo per il livello web. Worker in background, job pianificati, migrazioni, console di amministrazione e la tua stessa sessione psql attingono allo stesso tetto, e sono le connessioni che nessuno conta finché il tetto non viene raggiunto.
• Il raddoppio qui assunto è il caso comune di un rilascio progressivo con controllo di prontezza. Un rilascio che sostituisce tutto insieme può salire più in alto; uno che sostituisce un pod alla volta quasi non produce picco. Regola il numero di istanze se la tua strategia è diversa.
• I carichi serverless e con autoscaling rompono del tutto questa aritmetica, perché il numero di istanze non lo decidi tu. È il caso che un proxy — RDS Proxy, PgBouncer, Cloud SQL Auth Proxy — risolve davvero, multiplexando molte connessioni client su poche connessioni al database.
• Le connessioni inattive non sono gratuite. In PostgreSQL ciascuna è un processo che trattiene memoria; in MySQL ciascuna porta buffer per thread. Un pool generoso che resta perlopiù inattivo ti costa comunque la memoria che ha riservato.

Domande frequenti

Perché raddoppiare la domanda per un rilascio?

Perché un rilascio progressivo si sovrappone di proposito. La nuova istanza deve avviarsi, aprire il pool e superare il controllo di prontezza prima che la vecchia venga svuotata, quindi in quella finestra entrambe tengono pool pieni. Se la tua piattaforma sostituisce le istanze una alla volta la sovrapposizione è minore, ma la modalità di guasto è la stessa e vale la pena verificarla.

Il mio pool è ben sotto il limite e vedo comunque errori di connessione. Perché?

Di solito qualcosa fuori dal pool. Cerca worker, job pianificati e script una tantum che aprono connessioni proprie, una migrazione in corso durante il rilascio e connessioni perse da codice che non le restituisce. Il pool è solo la parte di domanda che hai configurato.

Un pool più grande è più veloce?

Oltre un certo punto no — è più lento. Una volta che ogni core del database è occupato, più connessioni concorrenti aggiungono cambi di contesto e contesa sui lock, non throughput. L'effetto misurabile di un pool sovradimensionato è di solito una peggiore latenza di coda, non un throughput migliore.

Dove si colloca un pooler come PgBouncer?

Tra i due numeri. Consente a un numero grande e variabile di connessioni client di condividere un numero piccolo e fisso di connessioni al database, esattamente ciò che questo strumento mostra necessario quando le istanze sono molte o imprevedibili. In modalità transaction pooling libera inoltre le connessioni tra le istruzioni invece di tenerle per l'intera sessione.