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à.
# Cliente: ClientRead
L’evento `Client:ClientRead` si verifica quando Aurora PostgreSQL è in attesa di ricevere dati dal client.
**Topics**
+ [Versioni del motore supportate](#apg-waits.clientread.context.supported)
+ [Contesto](#apg-waits.clientread.context)
+ [Probabili cause di aumento delle attese](#apg-waits.clientread.causes)
+ [Azioni](#apg-waits.clientread.actions)
## 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 pool di connessioni**
PgBouncer ha un'impostazione di configurazione di rete di basso livello denominata`pkt_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.
**Topics**
+ [Posizionare i client nella stessa area di disponibilità e subnet VPC del cluster](#apg-waits.clientread.actions.az-vpc-subnet)
+ [Ridimensionare il client](#apg-waits.clientread.actions.scale-client)
+ [Utilizza istanze di generazione corrente](#apg-waits.clientread.actions.db-instance-class)
+ [Aumentare la larghezza di banda di rete](#apg-waits.clientread.actions.increase-network-bandwidth)
+ [Monitora il massimo delle prestazioni di rete](#apg-waits.clientread.actions.monitor-network-performance)
+ [Monitorare le transazioni nello stato «inattivo nella transazione»](#apg-waits.clientread.actions.check-idle-in-transaction)
### 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 [Frame jumbo (9001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) nella *Guida per l’utente di Amazon EC2*.
Per informazioni sulle classi di istanza database, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md). 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
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](Aurora.AuroraMonitoring.Metrics.md)
### 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) nella *Guida per l’utente di Amazon EC2* e [Monitoraggio delle prestazioni di rete per l’istanza EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitoring-network-performance-ena.html) 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
```