Client:ClientRead - Amazon Aurora
Versioni del motore supportateContestoProbabili cause di aumento delle atteseAzioni

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à.

Client:ClientRead

L’evento Client:ClientRead si verifica quando Aurora PostgreSQL è in attesa di ricevere dati dal client.

Versioni del motore supportate

Queste informazioni relative all’evento di attesa sono supportate per Aurora PostgreSQL versione 10 e successive.

Contesto

Un cluster Aurora PostgreSQL DB è in attesa di ricevere dati dal client. Il cluster Aurora PostgreSQL DB deve ricevere i dati dal client prima di poter inviare più dati al client. Il tempo in cui il cluster attende prima di ricevere i dati dal client è un evento Client:ClientRead.

Probabili cause di aumento delle attese

Le cause comuni della comparsa dell’evento Client:ClientRead che appare nelle prime attese includono:

Maggiore latenza di rete

Potrebbe esserci una maggiore latenza di rete tra il cluster Aurora PostgreSQL DB e il client. Una maggiore latenza di rete aumenta il tempo necessario per la ricezione dei dati dal client del cluster DB.

Aumento del carico sul client

Potrebbe esserci una pressione della CPU o una saturazione della rete sul client. Un aumento del carico sul client può ritardare la trasmissione dei dati dal client al cluster Aurora PostgreSQL DB.

Eccesso di viaggi di andata e ritorno in rete

Un gran numero di viaggi di andata e ritorno in rete tra il cluster Aurora PostgreSQL DB e il client possono ritardare la trasmissione dei dati dal client al cluster Aurora PostgreSQL DB.

Operazione copia di grandi dimensioni

Durante un’operazione di copia, i dati vengono trasferiti dal file system del client al cluster di database Aurora PostgreSQL. L’invio di una grande quantità di dati al cluster di database può ritardare la trasmissione dei dati dal client al cluster di database.

Connessione client inattiva

Una connessione a un’istanza database di Aurora PostgreSQL è inattiva in stato di transazione ed è in attesa che un client invii più dati o un comando. Questo stato può comportare un aumento degli eventi Client:ClientRead.

PGBouncer utilizzato per il connection pooling

PGBouncer ha un’impostazione di configurazione di rete di basso livello denominata pkt_buf, che è impostata su 4.096 per impostazione predefinita. Se il carico di lavoro invia pacchetti di query superiori a 4.096 byte tramite PGBouncer, consigliamo di aumentare l’impostazione pkt_buf a 8.192. Se la nuova impostazione non diminuisce il numero di eventi Client:ClientRead, consigliamo di aumentare l’impostazione pkt_buf su valori più grandi, come 16.384 o 32.768. Se il testo della query è grande, l’impostazione più grande può essere particolarmente utile.

Azioni

Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.

Posizionare i client nella stessa area di disponibilità e subnet VPC del cluster

Per ridurre la latenza di rete e aumentare il throughput di rete, posizionare i client nella stessa subnet di Availability Zone e Virtual Private Cloud (VPC) del cluster Aurora PostgreSQL DB. Assicurarsi che i client siano il più geograficamente vicini possibile al cluster DB.

Ridimensionare il client

Utilizzando Amazon CloudWatch o altri parametri host, stabilire se il proprio client è attualmente vincolato dalla CPU o dalla larghezza di banda di rete o entrambi. Se il client è vincolato, ridimensionare il client di conseguenza.

Utilizza istanze di generazione corrente

In alcuni casi, potresti non utilizzare una classe di istanza DB che supporta i frame jumbo. Se stai eseguendo l’applicazione su Amazon EC2, considera l’utilizzo di un’istanza di generazione corrente per il client. Inoltre, configura l’unità di trasmissione massima (MTU) sul sistema operativo client. Questa tecnica potrebbe ridurre il numero di round trip di rete e aumentare il throughput di rete. Per ulteriori informazioni, consulta Frame jumbo (9001 MTU) nella Guida per l’utente di Amazon EC2.

Per informazioni sulle classi di istanza database, consulta Classi di istanze database Amazon Aurora. Per determinare la classe di istanza DB equivalente a un tipo di istanza Amazon EC2, posizionare db. prima del nome del tipo di istanza Amazon EC2. Ad esempio, l’istanza Amazon EC2 r5.8xlarge è equivalente alla classe di istanza database db.r5.8xlarge.

Aumentare la larghezza di banda di rete

Utilizza i parametri Amazon CloudWatch NetworkReceiveThroughput e NetworkTransmitThroughput per monitorare il traffico di rete in entrata e in uscita sul cluster DB. Questi parametri possono aiutarti a determinare se la larghezza di banda della rete è sufficiente per il tuo carico di lavoro.

Se la larghezza di banda della rete non è sufficiente, aumentala. Se il file client AWS o l’istanza database sta raggiungendo i limiti di larghezza di banda di rete, l’unico modo per aumentare la larghezza di banda è aumentare la dimensione dell’istanza database.

Per ulteriori informazioni sui parametri CloudWatch, consultare CloudWatch Parametri Amazon per Amazon Aurora.

Monitora il massimo delle prestazioni di rete

Se utilizzi client Amazon EC2, Amazon EC2 fornisce il massimo per i parametri delle prestazioni di rete, inclusa la larghezza di banda aggregata in entrata e in uscita. Fornisce inoltre il monitoraggio della connessione per garantire che i pacchetti vengano restituiti come previsto e l’accesso ai servizi locali per servizi come il DNS (Domain Name System). Per monitorare questi massimi, utilizza un driver di rete avanzato e monitora le prestazioni di rete per il client.

Per ulteriori informazioni, consulta Monitoraggio delle prestazioni di rete per l’istanza EC2 nella Guida per l’utente di Amazon EC2 e Monitoraggio delle prestazioni di rete per l’istanza EC2 nella Guida per l’utente di Amazon EC2.

Monitorare le transazioni nello stato «inattivo nella transazione»

Controlla se hai un numero crescente di connessioni idle in transaction. Per fare ciò, monitora la colonna state nella tabella pg_stat_activity. Potrebbe essere possibile identificare l’origine della connessione eseguendo una query simile alla seguente.

select client_addr, state, count(1) from pg_stat_activity 
where state like 'idle in transaction%' 
group by 1,2 
order by 3 desc