Calcolatore connessioni massime del database

Quante connessioni ti concede davvero un database gestito

Ogni database gestito ha un tetto di connessioni, e nessuno dei tre grandi cloud lo fissa allo stesso modo. AWS lo ricava da una formula sulla memoria dell'istanza, Azure pubblica una tabella fissa per prodotto e Google Cloud SQL usa fasce di memoria che salgono a scatti. Questo strumento applica la regola pubblicata da ciascun provider, così vedi il tetto reale prima di dimensionare un pool su un'ipotesi.

Come funziona

• Applica la regola documentata del provider all'istanza che scegli, non una regola empirica.
• Mostra affiancati il risultato della formula e quello realistico, perché DBInstanceClassMemory è inferiore alla RAM dell'istanza.
• Confronta tutti e tre i cloud a parità di memoria, dove le differenze diventano impossibili da ignorare.
• Sottrae le connessioni che Azure riserva a replica e monitoraggio, così la cifra mostrata è quella utilizzabile dall'applicazione.

AWS RDS, dai parametri predefiniti documentati
  PostgreSQL   LEAST({DBInstanceClassMemory/9531392}, 5000)
  MySQL        {DBInstanceClassMemory/12582880}
  MariaDB 10.5+ LEAST({DBInstanceClassMemory/25165760}, 12000)

Azure Flexible Server
  una tabella pubblicata per prodotto, circa 107 per GiB, con tetto 5000
  meno 15 riservate a replica e monitoraggio

Google Cloud SQL
  fasce di memoria pubblicate, limite inferiore incluso
  3,75-6 GiB -> 100   6-7,5 -> 200    7,5-15 -> 400
  15-30      -> 500  30-60  -> 600   60-120 -> 800
  120+       -> 1000

Esempio pratico

Una db.r7g.xlarge con PostgreSQL — 4 vCPU e 32 GiB di memoria — e cosa comprano gli stessi 32 GiB altrove.

1. 32 GiB = 34.359.738.368 byte
2. 34.359.738.368 / 9.531.392 = 3.604 — la risposta della formula
3. il tetto di 5.000 non interviene a questa dimensione, quindi resta 3.604
4. ma DBInstanceClassMemory non è la RAM dell'istanza: RDS sottrae prima il sistema e i propri processi
5. applicando l'overhead documentato da AWS si arriva a circa 3.324 nella pratica
6. Azure a 32 GiB: 3.437 totali, 3.422 utilizzabili dopo le 15 riservate
7. Google Cloud SQL a 32 GiB: 600, perché 32 ricade nella fascia da 30 a 60 GiB

Hardware identico, e Cloud SQL ti dà un quinto di quanto danno gli altri due. Se sposti un servizio tra cloud, questa singola cifra ha più probabilità di far fallire la migrazione di qualsiasi cosa nel tuo schema.

Come leggere il risultato

• DBInstanceClassMemory non è la memoria riportata sulla scheda dell'istanza. RDS riserva memoria per il sistema operativo e i propri processi di gestione e calcola la formula su ciò che resta. AWS documenta il divario con un esempio: un'istanza da 8 GiB rende circa 630 connessioni dove la divisione ingenua ne dà 683. È circa l'8% in meno, e vale a ogni dimensione.
• Google Cloud SQL usa fasce pubblicate anziché una formula, quindi il limite non cresce in modo continuo con la memoria: dentro una fascia non cresce affatto. Ogni istanza da 30 GiB fino a poco sotto i 60 GiB ottiene le stesse 600 connessioni, quindi raddoppiare la memoria dentro una fascia non compra nulla e l'intero aumento cade sul confine.
• Azure tratta B1ms come caso speciale a 50 connessioni, fuori dallo schema per GiB altrimenti coerente. Per questo lo strumento riproduce la tabella Azure alla lettera invece di interpolarvi una retta.
• Sono valori predefiniti, non limiti rigidi. max_connections è un parametro modificabile su tutti e tre i cloud. Alzarlo di solito è la correzione sbagliata, perché ogni connessione costa memoria e un processo — il motivo stesso per cui il valore predefinito segue la memoria.
• Un limite di connessioni non è un obiettivo di concorrenza. Postgres non diventa più veloce al crescere delle connessioni; oltre qualche multiplo del numero di core, più connessioni significano più cambi di contesto e meno throughput. Usa un pooler e tieni il pool ben sotto il tetto.

Domande frequenti

Perché la mia istanza riporta un max_connections diverso?

Tre motivi comuni. Il gruppo di parametri potrebbe essere stato modificato, e allora il tuo valore sostituisce del tutto la formula. La versione del motore conta: MariaDB ha cambiato il divisore in 10.5. E su AWS la cifra si sposta un poco con la memoria esatta riportata dall'host, ed è per questo che lo strumento mostra entrambi i valori.

Conviene alzare semplicemente max_connections?

Di solito no. Ogni connessione PostgreSQL è un processo con memoria propria e ogni connessione MySQL porta buffer per thread. Alzare il tetto sposta il guasto dalle connessioni rifiutate, visibili e recuperabili, alla pressione di memoria e all'OOM killer, che non sono né l'una né l'altra cosa. Un pooler di connessioni è quasi sempre la risposta migliore.

Una replica di lettura ha lo stesso limite?

Ha quello della propria classe di istanza, spesso identico perché le repliche di solito rispecchiano il primario. Ma le sue connessioni si contano a parte, quindi indirizzare le letture alla replica guadagna margine reale sul primario invece di limitarsi a spostare il problema.

Perché Cloud SQL è così più basso?

Google dimensiona il valore predefinito su quanto l'istanza serve bene, non su quanto accetta tecnicamente, e presume che i carichi con molte connessioni stiano dietro un pooler. È una scelta progettuale, non un vincolo hardware — ma viene applicata, quindi ti vincola comunque.

Fonti

• Amazon RDS — quote e vincoli
• Amazon RDS — classi di istanza DB
• Azure Database for PostgreSQL — limiti
• Cloud SQL per PostgreSQL — flag