Panoramica del pool di connessioni gestito

Il pool di connessioni gestito ti consente di scalare i carichi di lavoro ottimizzando l'utilizzo delle risorse e la latenza delle connessioni per le istanze Cloud SQL. PostgreSQL crea un nuovo processo per ogni connessione, che comporta un overhead di memoria utilizzata e di configurazione della connessione. Nelle architetture che stabiliscono frequentemente molte connessioni di breve durata, come le applicazioni serverless o di microservizi 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 di database esistenti.

Pool 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 di pool di connessioni è costituito da uno o più pool di connessioni. Un pooler di connessioni è un servizio di proxy di database che gestisce e instrada le connessioni di database tra le applicazioni client e il server di database.

Un pool di connessioni gestisce i pool di connessioni come un gruppo di connessioni server di database riutilizzabili aperte per ogni coppia di database e utenti.

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

  • Se nel pool è disponibile una connessione server inattiva, il pool di connessioni la assegna alla richiesta client.
  • Se non è disponibile una connessione server inattiva e non è stato raggiunto il limite del pool (max_pool_size), il pool di connessioni crea una nuova connessione server nel pool.
  • Se tutte le connessioni 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 server.
  • Al termine della richiesta, la connessione server torna al pool di connessioni per essere riutilizzata.

Relazione tra pool di connessioni e pool

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

Se l'istanza esegue più pool di connessioni, ogni pool di connessioni gestisce in modo indipendente il proprio set separato di pool di connessioni per le coppie di database e utenti a cui è indirizzato.

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

  • Scalabilità del cluster di pool di connessioni: il numero di pool 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 pool di connessioni). In questo modo, il pool di connessioni non diventa un collo di bottiglia. Le connessioni client in entrata vengono distribuite tra i pool di connessioni disponibili. Ad esempio:

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

  • Scalabilità di pool di connessioni e pool: poiché i pool di connessioni operano in modo indipendente, tutte le opzioni di configurazione vengono applicate per ogni pool 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 pool di connessioni. Ad esempio, se max_pool_size è impostato su 50 in un'istanza che esegue 2 pool di connessioni (8 vCPU), ogni pool di connessioni può aprire fino a 50 connessioni server per una coppia di database e utenti specifica, consentendo un totale di un massimo di 100 connessioni server nell'istanza per quel pool. Il dimensionamento accurato del pool è fondamentale per le prestazioni: se imposti un 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 delle connessioni client: anche i limiti delle connessioni client e il comportamento di timeout vengono configurati per ogni pool di connessioni. I parametri principali includono:

    • max_client_connections: limita il numero massimo di connessioni client consentite per ogni pool di connessioni (il valore predefinito è 5000 connessioni per ogni pool di connessioni).
    • client_connection_idle_timeout: controlla la durata durante la quale una connessione client può rimanere inattiva prima del timeout.
    • query_wait_timeout: controlla la durata durante la quale una query attende 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 pool di connessioni gestito per qualsiasi carico di lavoro transazionale, offre il massimo vantaggio in termini di throughput e latenza per le applicazioni che contengono connessioni di breve durata o che comportano un aumento delle connessioni.
  • Per le connessioni di lunga durata, le prestazioni della connessione che utilizzano 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 all'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ù su come attivare il 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 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ù su come eseguire la manutenzione self-service, consulta Eseguire 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 pooling:

  • transaction (impostazione predefinita): 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 uno stato della sessione. Ciò riduce l'efficienza del pooling. Quando un client si disconnette, la connessione server torna al pool di connessioni.

Opzioni di configurazione avanzate

Puoi personalizzare il pool di connessioni gestito 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 utenti in ogni pool di connessioni. Questa configurazione viene applicata per pool di connessioni. Determina questo valore in base alle dimensioni dell'istanza e ai requisiti di dimensioni del pool.

Il valore predefinito è 50 connessioni per coppia di database e utenti 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 di 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 ogni pool di connessioni quando si utilizza il pool di connessioni gestito. Determina questo valore in base alle dimensioni dell'istanza e ai requisiti di dimensioni del pool.

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

Se imposti questa opzione su 0 disattivi il supporto delle istruzioni preparate supportate. 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 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 durante il quale una query attende una connessione server in un pool prima del timeout.

Se imposti questa opzione su 0, la disattivi, consentendo l'accodamento indefinito dei client queuing. 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 per impostazione predefinita non vengono monitorati nei pacchetti di avvio del pool di connessioni gestito.
server_lifetime Il tempo massimo durante il quale una connessione server non viene utilizzata 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 le seguenti limitazioni:

  • L'attivazione 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 la versione 1.23 o precedenti di Go, 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
    • Tabelle temporanee PRESERVE/DELETE ROW
    • LOAD
    • Blocchi di consulenza a livello di sessione

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

  • 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 Archivia 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 gestito, 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 server che un pool di connessioni nel pool di connessioni gestito 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 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 gestito quando imposti il flag max_connections per il 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 Configurare i flag di database.

Passaggi successivi