Panoramica del pool di connessioni gestito

Il pool di connessioni gestite ti consente di scalare i workload ottimizzando l'utilizzo delle risorse e la latenza di connessione per le tue istanze Cloud SQL. PostgreSQL crea un nuovo processo per ogni connessione, il che comporta un overhead per la memoria utilizzata e la configurazione della connessione. Nelle architetture che stabiliscono spesso molte connessioni di breve durata, come i microservizi o le applicazioni serverless in esecuzione su Cloud Run, questo overhead può influire sulle prestazioni e sulla scalabilità del database.

Con il pool di connessioni gestito abilitato, i client si connettono a un cluster di pool di connessioni intermedio anziché direttamente al server di database. Questa assegnazione dinamica offre miglioramenti delle prestazioni, soprattutto per le connessioni scalate, assorbendo i picchi di connessione improvvisi e riutilizzando le connessioni al database esistenti.

Pooler di connessioni e pool di connessioni

Quando le applicazioni client si connettono a un'istanza con il pool di connessioni gestito abilitato, si connettono a un cluster di pool di connessioni intermedio anziché direttamente al server di database. Il cluster del pool di connessioni è composto da uno o più pooler di connessioni. Un pooler di connessioni è un servizio di proxy del database che gestisce e instrada le connessioni al database tra le applicazioni client e il server del database.

Un pooler di connessioni gestisce i pool di connessioni come un gruppo di connessioni al server di database aperte e riutilizzabili per coppia di database e utente.

Quando un'applicazione client autenticata si connette a un database come utente specifico, il pooler di connessioni indirizza la richiesta al pool di connessioni corrispondente:

  • Se nel pool è disponibile una connessione server inattiva, il pooler di connessioni la assegna alla richiesta del client.
  • Se non è disponibile una connessione al server inattiva e il limite del pool (max_pool_size) non è stato raggiunto, il pooler di connessioni crea una nuova connessione al server nel pool.
  • Se tutte le connessioni del server nel pool sono in uso e il limite del pool è stato raggiunto, il client passa a uno stato di attesa finché non diventa disponibile una connessione del server.
  • Al termine della richiesta, la connessione al server torna al pool di connessioni per essere riutilizzata.

Relazione tra pooler e pool

Un singolo pooler di connessioni può gestire più pool di connessioni contemporaneamente, con un pool per ogni coppia univoca di database e utente del database che si connette tramite quel pooler.

Se l'istanza esegue più pooler di connessioni, ogni pooler di connessioni gestisce in modo indipendente il proprio insieme separato di pool di connessioni per le coppie di database e utenti indirizzate al pooler.

Le funzionalità di prestazioni e scalabilità del pool di connessioni gestito operano su più livelli:

  • Scalabilità del cluster del pool di connessioni: il numero di pooler di connessioni nel cluster scala automaticamente in base al numero di core vCPU di cui è stato eseguito il provisioning per l'istanza (dividendo il numero di vCPU per 4, con un minimo di 1 pooler di connessioni). In questo modo, il pooling delle connessioni non diventa un collo di bottiglia. Le connessioni client in entrata vengono distribuite tra i pooler di connessioni disponibili. Ad esempio:

    • Un'istanza con 2 o 4 vCPU esegue 1 pooler di connessioni.
    • Un'istanza con 8 vCPU esegue 2 pooler di connessioni.
    • Un'istanza con 16 vCPU esegue 4 pooler di connessioni.
    • Un'istanza con 32 vCPU esegue 8 pooler di connessioni.
    • Un'istanza con 64 vCPU esegue 16 pooler di connessioni.

  • Pooler e scalabilità dei pool: poiché i pooler di connessioni operano in modo indipendente, tutte le opzioni di configurazione vengono applicate per pooler di connessioni anziché a livello globale nell'istanza. Le connessioni al server vengono create on demand fino a un limite massimo definito da max_pool_size per ogni pool gestito in ogni pooler di connessioni. Ad esempio, se max_pool_size è impostato su 50 su un'istanza che esegue 2 pooler di connessioni (8 vCPU), ogni pooler di connessioni può aprire fino a 50 connessioni server per una coppia di database e utente specifica, consentendo un totale di massimo 100 connessioni server nell'istanza per quel pool. Il dimensionamento accurato del pool è fondamentale per le prestazioni: l'impostazione di un valore troppo basso può comportare tempi di attesa della connessione più lunghi, mentre l'impostazione di un valore troppo alto può sprecare risorse del server di database.

  • Configurazioni delle connessioni client: i limiti delle connessioni client e il comportamento di timeout vengono configurati anche per pooler di connessioni. I parametri principali includono:

    • max_client_connections: limita il numero massimo di connessioni client consentite per pooler di connessioni (il valore predefinito è 5000 connessioni per ogni pooler di connessioni).
    • client_connection_idle_timeout: controlla la durata per cui una connessione client può rimanere inattiva prima di andare in timeout.
    • query_wait_timeout: controlla la durata dell'attesa di una query per una connessione server disponibile nel pool prima del timeout.

Casi d'uso e considerazioni

Quando utilizzi il pool di connessioni gestito, tieni presente quanto segue:

  • Sebbene sia possibile utilizzare il pool di connessioni gestite per qualsiasi workload transazionale, offre i maggiori vantaggi in termini di throughput e latenza per le applicazioni che contengono connessioni di breve durata o per le applicazioni che generano un picco di connessioni.
  • Per le connessioni di lunga durata, le prestazioni della connessione che utilizza il pool di connessioni gestito possono essere leggermente inferiori rispetto a quelle di una connessione diretta. In questo caso, il pool di connessioni gestito fornisce la scalabilità delle connessioni quando il numero di connessioni è molto elevato. Tuttavia, per le applicazioni che in genere stabiliscono connessioni di lunga durata, è consigliabile evitare di utilizzare il pooling delle connessioni.
  • Puoi utilizzare Identity and Access Management per proteggere le connessioni alla tua istanza a seconda della porta utilizzata dal pool di connessioni gestite. Per saperne di più su come funziona IAM in Cloud SQL e sulle sue limitazioni, consulta Autenticazione IAM.

Per saperne di più sull'abilitazione del pool di connessioni gestito, consulta Configura il pool di connessioni gestito.

Requisiti

Per utilizzare il pool di connessioni gestite, l'istanza deve soddisfare i seguenti requisiti:

  • L'istanza deve essere un'istanza Cloud SQL Enterprise Plus.
  • Devi essere connesso all'istanza utilizzando solo una connessione diretta o il Cloud SQL Auth Proxy.
  • L'istanza deve essere configurata per l'accesso privato ai servizi, utilizzare un IP pubblico o avere Private Service Connect abilitato.
  • L'istanza deve utilizzare la nuova architettura di rete Cloud SQL.
  • Il pool di connessioni gestito richiede un numero di versione di manutenzione minimo di POSTGRES_$version.R20250727.00_14. Per saperne di più sull'esecuzione della manutenzione self-service, consulta Esegui la manutenzione self-service.

Opzioni di pooling

Il pool di connessioni gestito ti consente di gestire il modo in cui le connessioni vengono raggruppate in pool utilizzando il parametro pool_mode. Puoi utilizzare le seguenti opzioni di pooling:

  • transaction (valore predefinito): raggruppa le connessioni a livello di transazione. Le connessioni vengono restituite al pool al termine di ogni transazione. Cloud SQL consiglia di utilizzare la modalità di pooling transaction per le connessioni di breve durata.
  • session: raggruppa le connessioni a livello di sessione. Ogni sessione utilizza una connessione al server dedicata che mantiene uno stato della sessione. Ciò riduce l'efficienza del pooling. Quando un client si disconnette, la connessione al server torna al pool di connessioni.

Opzioni di configurazione avanzate

Puoi personalizzare il pooling delle connessioni gestite utilizzando le seguenti opzioni di configurazione.

Nome della configurazione Descrizione
max_pool_size Il numero massimo di connessioni server consentite a una coppia di database e utente in ogni pool di connessioni. Questa configurazione viene applicata per pooler di connessioni. Determina questo valore in base alle dimensioni dell'istanza e ai requisiti delle dimensioni del pool.

Il valore predefinito è50 connessioni per coppia database-utente per ogni pool di connessioni.
min_pool_size Il numero minimo di connessioni server disponibili in qualsiasi momento in ogni pool di connessioni. Questa configurazione viene applicata per pooler di connessioni. Determina questo valore in base alle dimensioni dell'istanza e ai requisiti delle dimensioni del pool.

Se il numero di connessioni server è inferiore a min_pool_size, questa impostazione aggiunge altre connessioni server al pool. In questo modo è possibile gestire gli aumenti improvvisi del carico del database dopo periodi di inattività e garantire che le connessioni siano disponibili e pronte per l'uso.

Il valore predefinito è 0 connessioni.
max_client_connections Il numero massimo di connessioni client consentite per pooler di connessioni quando utilizzi il pool di connessioni gestito. Determina questo valore in base ai requisiti di dimensione dell'istanza e del pool.

Il valore predefinito è 5,000 connessioni per ogni pooler di connessioni.
max_prepared_statements Il numero massimo di istruzioni preparate denominate a livello di protocollo supportate per pooler di connessioni in modalità di pooling transaction. Determina questo valore in base alle dimensioni dell'istanza e ai requisiti delle dimensioni del pool.

Se imposti questa opzione su 0, il supporto delle istruzioni preparate viene disattivato. Per prestazioni ottimali, questo valore deve superare il numero di istruzioni preparate di uso comune nel database. Un numero elevato di istruzioni preparate nel pool di connessioni gestito può causare un aumento della memoria utilizzata.

Il valore predefinito è 0 istruzioni.
client_connection_idle_timeout Il tempo durante il quale una connessione client rimane inattiva prima del timeout. Questo valore può variare da 0 a 2,147,483 secondi e il valore predefinito è 0 secondi.
server_connection_idle_timeout Il tempo durante il quale una connessione al server rimane inattiva prima del timeout. Questo valore può variare da 0 a 2,147,483 secondi e il valore predefinito è 600 secondi.
query_wait_timeout Il tempo di attesa di una query per una connessione server in un pool prima del timeout.

Se questa opzione viene impostata su 0, viene disattivata, il che consente l'accodamento dei client a tempo indeterminato. Se attivi questa opzione, i server che non rispondono non possono bloccare le connessioni.

Questo valore può variare da 0 a 2,147,483 secondi e il valore predefinito è 120 secondi.
ignore_startup_parameters I parametri che vuoi ignorare, che non vengono monitorati per impostazione predefinita nei pacchetti di avvio del pool di connessioni gestito.
server_lifetime Il tempo massimo di inutilizzo di una connessione al server prima che venga chiusa dal pool di connessioni gestite. Se il valore è impostato su 0 secondi, la connessione viene chiusa immediatamente dopo l'utilizzo.

Il valore predefinito è 3600 secondi.

Limitazioni

Quando utilizzi il pool di connessioni gestite con le istanze Cloud SQL Enterprise Plus, tieni presente queste limitazioni:

  • L'abilitazione del pool di connessioni gestito su un'istanza esistente comporta il riavvio del database.
  • Il pool di connessioni gestite può essere utilizzato solo con Cloud SQL Auth Proxy versione 2.15.2 e successive.
  • Se utilizzi il connettore Go di Cloud SQL, ti consigliamo una versione Go minima di 1.24. Se utilizzi Go versione 1.23 o precedenti, potresti riscontrare limitazioni delle prestazioni quando utilizzi il pool di connessioni gestito.

  • Se utilizzi il pool di connessioni gestito in modalità di pooling transaction, le seguenti funzionalità SQL non sono supportate:

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • PRESERVE/DELETE ROW tabelle temporanee
    • LOAD
    • Blocchi di avviso a livello di sessione

  • Se utilizzi la libreria di interfacce di database asyncpg per il pooler di pool di connessioni gestite sulle porte 3307 e 6432, devi aggiornare max_prepared_statements a un valore maggiore di 0 per abilitare il supporto delle istruzioni preparate nel pooler di pool di connessioni gestite.

  • Se utilizzi Cloud SQL per PostgreSQL versione 17, l'opzione sslnegotiation=direct non è supportata.

  • Il monitoraggio dell'IP client non è supportato con il pooling delle connessioni gestite. Se attivi l'opzione Archivia gli indirizzi IP client in Query Insights, gli indirizzi IP client vengono visualizzati come local anziché come indirizzo IP stesso.

Porte utilizzate dal pool di connessioni gestito

Quando abiliti il pool di connessioni gestite, le porte utilizzate dalle istanze Cloud SQL per gestire il traffico del database cambiano. Puoi utilizzare Identity and Access Management per proteggere le connessioni, a seconda della porta.

Le porte utilizzate dal pool di connessioni gestito e le relative opzioni IAM disponibili sono le seguenti:

Connessioni server utilizzate dal pool di connessioni gestito

La configurazione del database max_connections limita il numero massimo di connessioni al server che un pooler può utilizzare nel pool di connessioni gestite. Cloud SQL consiglia di modificare questo valore in base ai requisiti del workload dell'istanza e alle dimensioni dell'istanza del database. Durante il carico di picco, il numero di connessioni per l'autenticazione può diventare molto elevato.

Se utilizzi il valore predefinito max_pool_size di 50 connessioni per pool, ti consigliamo di riservare almeno 15 connessioni server per CPU per il pool di connessioni gestite quando imposti il flag max_connections per il tuo database. Per saperne di più sul flag max_connections, consulta Numero massimo di connessioni simultanee. Per modificare il flag max_connections per l'istanza, consulta Configura i flag di database.

Passaggi successivi