Cliente: 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.

Context

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 Aurora PostgreSQL DB. L'invio di una grande quantità di dati al cluster DB può ritardare la trasmissione dei dati dal client al cluster DB.

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 pool di connessioni

PgBouncer ha un'impostazione di configurazione di rete di basso livello denominatapkt_buf, che per impostazione predefinita è impostata su 4.096. Se il carico di lavoro consiste nell'invio di pacchetti di query di dimensioni superiori a 4.096 byte PgBouncer, si consiglia di aumentare l'impostazione a 8.192. pkt_buf 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.

Argomenti

• Posizionare i client nella stessa area di disponibilità e subnet VPC del cluster
• Ridimensionare il client
• Utilizza istanze di generazione corrente
• Aumentare la larghezza di banda di rete
• Monitora il massimo delle prestazioni di rete
• Monitorare le transazioni nello stato «inattivo nella transazione»

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 relativi all'host, stabilisci se il tuo client è attualmente limitato dalla CPU o dalla larghezza di banda della rete o da 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 Jumbo frames (9001 MTU) nella Amazon EC2 User Guide.

Per informazioni sulle classi di istanza database, consulta Aurora Classi di istanze database. 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 DB db.r5.8xlarge.

Aumentare la larghezza di banda di rete

Usa NetworkReceiveThroughput i CloudWatch parametri di NetworkTransmitThroughput Amazon 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 AWS client o l'istanza DB stanno raggiungendo i limiti di larghezza di banda di rete, l'unico modo per aumentare la larghezza di banda è aumentare le dimensioni dell'istanza DB.

Per ulteriori informazioni sulle CloudWatch metriche, consulta. 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 Amazon EC2 nella Guida per l'utente di Amazon EC2 e Monitoraggio delle prestazioni di rete per l'istanza Amazon 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