Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Gestione del tasso di abbandono della connessione Aurora Postgre SQL RDS con pooling

Quando le applicazioni client si connettono e si disconnettono così spesso da rallentare il tempo di risposta del cluster Aurora SQL Postgre DB, si dice che il cluster stia riscontrando un abbandono della connessione. Ogni nuova connessione all'endpoint del cluster Aurora Postgre SQL DB consuma risorse, riducendo così le risorse che possono essere utilizzate per elaborare il carico di lavoro effettivo. È consigliabile gestire il problema dell’abbandono della connessione seguendo alcune delle best practice descritte di seguito.

Per cominciare, puoi migliorare i tempi di risposta sui cluster Aurora SQL Postgre DB che presentano alti tassi di abbandono delle connessioni. A tale scopo, è possibile utilizzare un pool di connessioni, ad esempio Proxy. RDS Un pool di connessioni fornisce una cache di connessioni pronte all'uso per i client. Quasi tutte le versioni di Aurora SQL Postgre supportano Proxy. RDS Per ulteriori informazioni, consulta RDSProxy Amazon con Aurora Postgre SQL.

Se la tua versione specifica di Aurora Postgre SQL non supporta RDS Proxy, puoi utilizzare un altro connection pooler compatibile con PostgreSQL, ad esempio. PgBouncer Per saperne di più, consulta il sito Web. PgBouncer

Per vedere se il tuo cluster Aurora Postgre SQL DB può trarre vantaggio dal pool di connessioni, puoi controllare le connessioni e le disconnessioni nel postgresql.log file. Puoi anche utilizzare Performance Insights per scoprire il tasso di abbandono delle connessioni registrato dal tuo cluster Aurora SQL Postgre DB. Di seguito sono disponibili informazioni su entrambi gli argomenti.

Registrazione di connessioni e disconnessioni

SQLlog_connectionsPostgre e log_disconnections i parametri possono acquisire connessioni e disconnessioni all'istanza writer del cluster Aurora Postgre DB. SQL Per impostazione predefinita, questi parametro sono disattivati. Per attivare questi parametri, utilizza un gruppo di parametri personalizzati e attivali modificando il valore in 1. Per ulteriori informazioni sui gruppi di parametri, consulta Gruppi di parametri del cluster DB per i cluster Amazon Aurora DB. Per verificare le impostazioni, connettiti all'endpoint del cluster DB per Aurora SQL Postgre utilizzando psql e interrogando come segue.

labdb=> SELECT setting FROM pg_settings
  WHERE name = 'log_connections';
 setting
---------
on
(1 row)
labdb=> SELECT setting FROM pg_settings
  WHERE name = 'log_disconnections';
setting
---------
on
(1 row)

Con entrambi questi parametri attivati, il registro acquisisce tutte le nuove connessioni e disconnessioni. Per ogni nuova connessione autorizzata, vengono visualizzati utente e database. Al momento della disconnessione, viene registrata anche la durata della sessione, come mostrato nell'esempio seguente.

2022-03-07 21:44:53.978 UTC [16641] LOG: connection authorized: user=labtek database=labdb application_name=psql
2022-03-07 21:44:55.718 UTC [16641] LOG: disconnection: session time: 0:00:01.740 user=labtek database=labdb host=[local]

Per verificare l’abbandono della connessione nell'applicazione, attiva questi parametri se non è già stato fatto. Quindi raccogli i dati nel SQL registro di Postgre per l'analisi eseguendo l'applicazione con un carico di lavoro e un periodo di tempo realistici. Puoi visualizzare il file di registro nella console. RDS Scegli l'istanza writer del tuo cluster Aurora Postgre SQL DB, quindi scegli la scheda Logs & events. Per ulteriori informazioni, consulta Visualizzazione ed elenco dei file di log del database.

Oppure, puoi scaricare il file di registro dalla console e utilizzare la seguente sequenza di comandi. Questa sequenza individua il numero totale di connessioni autorizzate e interrotte al minuto.

grep "connection authorized\|disconnection: session time:" postgresql.log.2022-03-21-16|\
awk {'print $1,$2}' |\
sort |\
uniq -c |\
sort -n -k1

Nell'output di esempio, è possibile visualizzare un picco nelle connessioni autorizzate seguito da disconnessioni a partire dalle 16:12:10.

.....
,......
.........
5 2022-03-21 16:11:55 connection authorized:
9 2022-03-21 16:11:55 disconnection: session
5 2022-03-21 16:11:56 connection authorized:
5 2022-03-21 16:11:57 connection authorized:
5 2022-03-21 16:11:57 disconnection: session
32 2022-03-21 16:12:10 connection authorized:
30 2022-03-21 16:12:10 disconnection: session
31 2022-03-21 16:12:11 connection authorized:
27 2022-03-21 16:12:11 disconnection: session
27 2022-03-21 16:12:12 connection authorized:
27 2022-03-21 16:12:12 disconnection: session
41 2022-03-21 16:12:13 connection authorized:
47 2022-03-21 16:12:13 disconnection: session
46 2022-03-21 16:12:14 connection authorized:
41 2022-03-21 16:12:14 disconnection: session
24 2022-03-21 16:12:15 connection authorized:
29 2022-03-21 16:12:15 disconnection: session
28 2022-03-21 16:12:16 connection authorized:
24 2022-03-21 16:12:16 disconnection: session
40 2022-03-21 16:12:17 connection authorized:
42 2022-03-21 16:12:17 disconnection: session
40 2022-03-21 16:12:18 connection authorized:
40 2022-03-21 16:12:18 disconnection: session
.....
,......
.........
1 2022-03-21 16:14:10 connection authorized:
1 2022-03-21 16:14:10 disconnection: session
1 2022-03-21 16:15:00 connection authorized:
1 2022-03-21 16:16:00 connection authorized:

Con queste informazioni, puoi decidere se il carico di lavoro può trarre vantaggio da un pool di connessioni. Per analisi più dettagliate, puoi utilizzare Performance Insights.

Rilevamento dell’abbandono della connessione con Performance Insights

È possibile utilizzare Performance Insights per valutare il tasso di abbandono delle connessioni sul cluster DB Aurora SQL Postgre -Compatible Edition. Quando si crea un cluster Aurora Postgre SQL DB, l'impostazione per Performance Insights è attivata per impostazione predefinita. Se questa scelta è stata deselezionata al momento della creazione del cluster database, modifica il cluster per attivare la funzionalità. Per ulteriori informazioni, consulta Modifica di un cluster database Amazon Aurora.

Con Performance Insights in esecuzione sul cluster Aurora Postgre SQL DB, puoi scegliere le metriche che desideri monitorare. Puoi accedere a Performance Insights dal riquadro di navigazione nella console. È inoltre possibile accedere a Performance Insights dalla scheda Monitoring dell'istanza writer per il cluster Aurora Postgre SQL DB, come mostrato nell'immagine seguente.

Dalla console Performance Insights, scegli Manage metrics (Gestisci metriche). Per analizzare l'attività di connessione e disconnessione del cluster Aurora Postgre SQL DB, scegli le seguenti metriche. Queste sono tutte metriche di Postgre. SQL

Per salvare le impostazioni e visualizzare l'attività di connessione, scegli Update graph (Aggiorna grafico).

Nell'immagine seguente è visibile l'impatto dell'esecuzione di pgbench con 100 utenti. La linea che mostra le connessioni ha una pendenza costante verso l'alto. Per saperne di più su pgbench e su come usarlo, consulta pgbench nella documentazione di Postgre. SQL

L'immagine mostra che l'esecuzione di un carico di lavoro con un minimo di 100 utenti senza un pool di connessioni può causare un aumento significativo del numero di total_auth_attempts per tutta la durata dell'elaborazione del carico di lavoro.

Con il pool di connessioni RDS Proxy, i tentativi di connessione aumentano all'inizio del carico di lavoro. Dopo aver impostato il pool di connessioni, la media diminuisce. Le risorse utilizzate dall’uso di transazioni e backend rimangono coerenti per tutta l'elaborazione del carico di lavoro.

Per ulteriori informazioni sull'utilizzo di Performance Insights con il cluster Aurora Postgre SQL DB, consulta. Monitoraggio del carico del DB con Performance Insights su Amazon Aurora Per analizzare le metriche, consulta Per analizzare il parametro utilizzando il pannello di controllo di Performance Insights.

Dimostrazione dei vantaggi del pooling delle connessioni

Come accennato in precedenza, se si determina che il cluster Aurora Postgre SQL DB presenta un problema di abbandono della connessione, è possibile utilizzare RDS Proxy per migliorare le prestazioni. Di seguito, è disponibile un esempio che mostra le differenze nell'elaborazione di un carico di lavoro con e senza il pooling delle connessioni. L'esempio utilizza pgbench per modellare il carico di lavoro transazionale.

Così come psql, pgbench è un'applicazione SQL client Postgre che puoi installare ed eseguire dal tuo computer client locale. Puoi anche installarlo ed eseguirlo dall'EC2istanza Amazon che usi per gestire il tuo cluster Aurora SQL Postgre DB. Per ulteriori informazioni, consulta pgbench nella documentazione di Postgre. SQL

Per procedere con questo esempio, occorre creare innanzitutto l'ambiente pgbench nel database. Il seguente comando è il modello base per inizializzare le tabelle pgbench nel database specificato. Questo esempio utilizza l'account utente principale predefinito,postgres, per l’accesso. Modificalo secondo necessità per il tuo cluster Aurora SQL Postgre DB. L'ambiente pgbench viene creato in un database sull'istanza di scrittura del cluster.

pgbench -U postgres -h db-cluster-instance-1.111122223333.aws-region.rds.amazonaws.com -p 5432 -d -i -s 50 dbname

Per pgbench, specifica i seguenti parametri.

Dopo aver impostato l'ambiente pgbench, puoi eseguire test di benchmarking con e senza pooling delle connessioni. Il test predefinito consiste in una serie di cinque SELECT INSERT comandi per transazione che vengono eseguiti ripetutamente per il tempo specificato. UPDATE Puoi specificare il fattore di dimensionamento, il numero di client e altri dettagli per modellare i tuoi casi d'uso.

Ad esempio, il comando seguente esegue il benchmark per 60 secondi (opzione -T, per il tempo) con 20 connessioni simultanee (l'opzione -c). L'opzione -C determina l’esecuzione del test utilizzando una nuova connessione ogni volta, anziché una volta per sessione client. Questa impostazione fornisce un'indicazione del sovraccarico delle connessioni.

pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 -C labdb
Password:**********
pgbench (14.3, server 13.3)
  starting vacuum...end.
  transaction type: <builtin: TPC-B (sort of)>
    scaling factor: 50
    query mode: simple
    number of clients: 20
    number of threads: 1
    duration: 60 s
    number of transactions actually processed: 495
    latency average = 2430.798 ms
    average connection time = 120.330 ms
    tps = 8.227750 (including reconnection times)

L'esecuzione di pgbench sull'istanza writer di un cluster Aurora Postgre SQL DB senza riutilizzare le connessioni mostra che vengono elaborate solo circa 8 transazioni al secondo. Ciò fornisce un totale di 495 transazioni durante il test di 1 minuto.

Se riutilizzi le connessioni, la risposta del cluster Aurora SQL Postgre DB per il numero di utenti è quasi 20 volte più veloce. Con il riutilizzo, viene elaborato un totale di 9.042 transazioni rispetto alle 495 nello stesso periodo di tempo e per lo stesso numero di connessioni utente. La differenza è che in quello seguente, ogni connessione viene riutilizzata.

pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 labdb
Password:*********
pgbench (14.3, server 13.3)
      starting vacuum...end.
      transaction type: <builtin: TPC-B (sort of)>
      scaling factor: 50
      query mode: simple
      number of clients: 20
      number of threads: 1
      duration: 60 s
      number of transactions actually processed: 9042
      latency average = 127.880 ms
      initial connection time = 2311.188 ms
      tps = 156.396765 (without initial connection time)

Questo esempio mostra che il pooling delle connessioni può migliorare significativamente i tempi di risposta. Per informazioni sulla configurazione del RDS proxy per il cluster Aurora Postgre SQL DB, consulta. Utilizzo di Amazon RDS Proxy per Aurora