Panoramica del pool di connessioni gestito

Il pool di connessioni gestito ti consente di scalare i tuoi 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 sovraccarico di memoria utilizzata e di configurazione della connessione. Nelle architetture che stabiliscono spesso molte connessioni di breve durata, come microservizi o 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 intermediario anziché connettersi direttamente al server di database. Questa assegnazione dinamica migliora le prestazioni, soprattutto per le connessioni scalate, assorbendo i picchi improvvisi di connessione 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 intermediario anziché connettersi direttamente al server di database. Il cluster di pool di connessioni è costituito da uno o più pooler di connessioni. Un pooler di connessioni è un servizio proxy di database che gestisce e indirizza le connessioni di database tra le applicazioni client e il server di database.

Un pooler di connessioni gestisce i pool di connessioni come un gruppo di connessioni al server di database riutilizzabili aperte per ogni 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 non è stato raggiunto il limite del pool (max_pool_size), 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é una connessione del server non diventa disponibile.
  • 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 il pooler.

Se la tua istanza esegue più pooler di connessioni, ognuno di questi gestisce in modo indipendente il proprio insieme separato di pool di connessioni per le coppie di database e utenti a cui è indirizzato.

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

  • Scalabilità del cluster del pool di connessioni:il numero di pooler di connessioni nel cluster viene scalato 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 pool di 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 un 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à del 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 server vengono create su richiesta 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 specifica coppia di database e utente, consentendo un totale di massimo 100 connessioni server nell'istanza per quel pool. Il dimensionamento accurato del pool è fondamentale per le prestazioni: se imposti questo valore troppo basso, i tempi di attesa della connessione possono essere più lunghi, mentre se lo imposti troppo alto, le risorse del server di database possono essere sprecate.

  • Configurazioni della connessione client:i limiti e il comportamento di timeout della connessione client vengono configurati anche per ogni pooler di connessioni. I parametri chiave includono:

    • max_client_connections: limita il numero massimo di connessioni client consentite per ogni pooler di connessioni (il valore predefinito è 5000 connessioni per ogni pooler di connessioni).
    • client_connection_idle_timeout: controlla la durata durante la quale una connessione client può rimanere inattiva prima che scada il timeout.
    • query_wait_timeout: controlla la durata di 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 tu possa utilizzare il pooling di connessioni gestito per qualsiasi carico di lavoro transazionale, offre il massimo vantaggio in termini di throughput e latenza alle applicazioni che contengono connessioni di breve durata o che comportano un aumento improvviso delle connessioni.
  • Per le connessioni a 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à della connessione quando il numero di connessioni è molto elevato. Tuttavia, per le applicazioni che in genere stabiliscono connessioni di lunga durata, potresti voler evitare di utilizzare il pool di connessioni.
  • Puoi utilizzare Identity and Access Management per proteggere le connessioni alla tua istanza a seconda della porta utilizzata dal pool di connessioni gestito. 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 Configurare il pool di connessioni gestito.

Requisiti

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

  • L'istanza deve essere un'istanza Cloud SQL Enterprise Plus.
  • Devi connetterti all'istanza utilizzando solo una connessione diretta o il proxy di autenticazione Cloud SQL.
  • L'istanza deve essere configurata per l'accesso privato ai servizi, utilizzare un IP pubblico o essere una nuova istanza con 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 utilizzando il parametro pool_mode. Puoi utilizzare le seguenti opzioni di raggruppamento:

  • 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 server dedicata che mantiene lo stato della sessione. In questo modo si riduce l'efficienza del pooling. Quando un client si disconnette, la connessione del server torna al pool di connessioni.

Opzioni di configurazione avanzate

Puoi personalizzare il pool di connessioni gestito utilizzando le seguenti opzioni di configurazione.

Nome 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 ogni 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 database e coppia 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 ogni pool 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 all'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 dimensioni 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 in cui una connessione client rimane inattiva prima che scada il timeout. Questo valore può variare da 0 a 2,147,483 secondi e il valore predefinito è 0 secondi.
server_connection_idle_timeout Il tempo in cui una connessione 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 indefinito dei client. L'attivazione di questa opzione impedisce ai server che non rispondono di 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 nei pacchetti di avvio del pool di connessioni gestite per impostazione predefinita.
server_lifetime Il tempo massimo in cui una connessione server rimane inutilizzata prima che il pool di connessioni gestito la chiuda. Se il valore è impostato su 0 secondi, la connessione viene chiusa immediatamente dopo l'uso.

Il valore predefinito è 3600 secondi.

Limitazioni

Quando utilizzi il pool di connessioni gestito 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 gestito può essere utilizzato solo con il proxy di autenticazione Cloud SQL versione 2.15.2 e successive.
  • Se utilizzi il connettore del linguaggio Go di Cloud SQL, ti consigliamo una versione minima di Go 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 consulenza a livello di sessione

  • Se utilizzi la libreria di interfacce di database asyncpg per il pooler di Managed Connection Pooling 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 Managed Connection Pooling.

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

  • Il monitoraggio dell'IP client non è supportato con il pool di connessioni gestito. Se abiliti l'opzione Archivia gli indirizzi IP dei client in Query Insights, gli indirizzi IP dei client vengono visualizzati come local anziché l'indirizzo IP stesso.

Porte utilizzate dal pool di connessioni gestito

Quando abiliti il pool di connessioni gestito, le porte utilizzate dalle istanze Cloud SQL per erogare 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 server che un pooler in Managed Connection Pooling può utilizzare. Cloud SQL consiglia di modificare questo valore in base ai requisiti del carico di lavoro dell'istanza e alle dimensioni dell'istanza del database. Durante il picco di carico, 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 gestito quando imposti il flag max_connections per il tuo database. Per saperne di più sul flag max_connections, vedi Connessioni simultanee massime. Per modificare il flag max_connections per la tua istanza, consulta Configurare i flag di database.

Passaggi successivi