Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Cliente : ClientRead
L’événement `Client:ClientRead` se produit lorsqu’Aurora PostgreSQL attend de recevoir des données du client.
**Topics**
+ [Versions de moteur prises en charge](#apg-waits.clientread.context.supported)
+ [Contexte](#apg-waits.clientread.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#apg-waits.clientread.causes)
+ [Actions](#apg-waits.clientread.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente s’appliquent à Aurora PostgreSQL 10 et versions ultérieures.
## Contexte
Un cluster de bases de données Aurora PostgreSQL attend de recevoir des données du client. Le cluster de bases de données Aurora PostgreSQL doit recevoir les données du client avant de pouvoir envoyer plus de données au client. La période pendant laquelle le cluster attend avant de recevoir les données du client est un événement `Client:ClientRead`.
## Causes probables de l’augmentation du nombre d’événements d’attente
Les principales causes de l’événement d’attente `Client:ClientRead` sont les suivantes :
**Latence réseau accrue**
La latence réseau peut être accrue entre le cluster de bases de données Aurora PostgreSQL et le client. Une latence réseau plus élevée augmente le temps de réception des données du client par le cluster de bases de données.
**Charge accrue sur le client**
Le client peut être soumis à une pression exercée sur l’UC ou à une saturation du réseau. Une augmentation de la charge exercée sur le client peut retarder la transmission des données du client vers le cluster de bases de données Aurora PostgreSQL.
**Nombre excessif d’allers-retours réseau**
Un grand nombre d’allers-retours réseau entre le cluster de bases de données Aurora PostgreSQL et le client peut retarder la transmission des données du client vers le cluster de bases de données Aurora PostgreSQL.
**Opération de copie importante**
Lors d’une opération de copie, les données sont transférées du système de fichiers du client vers le cluster de bases de données Aurora PostgreSQL. L’envoi d’une grande quantité de données au cluster de bases de données peut retarder la transmission des données du client vers le cluster de bases de données.
**Connexion client inactive**
Une connexion à une instance de base de données Aurora PostgreSQL est inactive dans l’état de transaction et attend qu’un client envoie des données supplémentaires ou émette une commande. Cet état peut entraîner une augmentation des événements `Client:ClientRead`.
**PgBouncer utilisé pour le regroupement de connexions**
PgBouncer possède un paramètre de configuration réseau de bas niveau appelé`pkt_buf`, qui est défini sur 4 096 par défaut. Si la charge de travail envoie des paquets de requêtes de plus de 4 096 octets PgBouncer, nous vous recommandons d'augmenter le `pkt_buf` paramètre à 8 192. Si le nouveau paramètre ne permet pas de réduire le nombre d’événements `Client:ClientRead`, nous vous recommandons d’augmenter le paramètre `pkt_buf` en le définissant sur des valeurs plus élevées, telles que 16 384 ou 32 768. Si le texte de la requête est volumineux, un paramètre plus élevé peut être particulièrement utile.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [Placez les clients dans la même zone de disponibilité et le même sous-réseau VPC que le cluster](#apg-waits.clientread.actions.az-vpc-subnet)
+ [Procédez à la mise à l’échelle du client](#apg-waits.clientread.actions.scale-client)
+ [Utilisez des instances de la génération actuelle](#apg-waits.clientread.actions.db-instance-class)
+ [Augmentez la bande passante réseau](#apg-waits.clientread.actions.increase-network-bandwidth)
+ [Surveillez les valeurs maximales des métriques de performances réseau](#apg-waits.clientread.actions.monitor-network-performance)
+ [Surveillez les transactions dont l’état est « idle in transaction » (transaction inactive)](#apg-waits.clientread.actions.check-idle-in-transaction)
### Placez les clients dans la même zone de disponibilité et le même sous-réseau VPC que le cluster
Pour réduire la latence réseau et augmenter son débit, placez les clients dans la même zone de disponibilité et le même sous-réseau de cloud privé virtuel (VPC) que le cluster de bases de données Aurora PostgreSQL. Assurez-vous que les clients sont aussi proches que possible du cluster de bases de données géographiquement parlant.
### Procédez à la mise à l’échelle du client
À l'aide d'Amazon CloudWatch ou d'autres indicateurs de l'hôte, déterminez si votre client est actuellement limité par le processeur ou la bande passante du réseau, ou les deux. Si le client est soumis à des contraintes, mettez-le à l’échelle en conséquence.
### Utilisez des instances de la génération actuelle
La classe d’instance de base de données que vous utilisez ne prend peut-être pas en charge les trames jumbo. Si vous exécutez votre application sur Amazon EC2, pensez à utiliser une instance de génération actuelle pour le client. Configurez également l’unité de transmission maximale (MTU) sur le système d’exploitation client. Cette technique peut réduire le nombre d’allers-retours réseau et augmenter le débit du réseau. Pour plus d’informations, consultez [Trames jumbo (MTU de 9001)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) dans le *Guide de l’utilisateur Amazon EC2*.
Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md). Pour déterminer quelle classe d’instance de base de données est l’équivalent d’un type d’instance Amazon EC2, placez `db.` avant le nom du type d’instance Amazon EC2. Par exemple, l’instance Amazon EC2 `r5.8xlarge` est l’équivalent de la classe d’instance de base de données `db.r5.8xlarge`.
### Augmentez la bande passante réseau
Utilisez `NetworkReceiveThroughput` les CloudWatch métriques `NetworkTransmitThroughput` Amazon pour surveiller le trafic réseau entrant et sortant sur le cluster de base de données. Ces métriques peuvent vous aider à déterminer si la bande passante réseau est suffisante pour votre charge de travail.
Si la bande passante réseau est insuffisante, augmentez-la. Si le AWS client ou votre instance de base de données atteint les limites de bande passante du réseau, le seul moyen d'augmenter la bande passante est d'augmenter la taille de votre instance de base de données.
Pour plus d'informations sur CloudWatch les métriques, consultez[CloudWatch Métriques Amazon pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md).
### Surveillez les valeurs maximales des métriques de performances réseau
Si vous utilisez des clients Amazon EC2, Amazon EC2 fournit des valeurs maximales pour les métriques de performances réseau, y compris pour la bande passante réseau entrante et sortante agrégée. Il assure également le suivi des connexions pour garantir un retour optimal des paquets et un accès aux services locaux de liaison pour des services tels que le système de noms de domaine (DNS). Pour surveiller ces valeurs maximales, utilisez un pilote réseau amélioré à jour et surveillez les performances réseau de votre client.
Pour plus d’informations, consultez [ Surveillance des performances réseau de votre instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) dans le *Guide de l’utilisateur Amazon EC2* et [Surveillance des performances réseau de votre instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitoring-network-performance-ena.html) dans le *Guide de l’utilisateur Amazon EC2*.
### Surveillez les transactions dont l’état est « idle in transaction » (transaction inactive)
Déterminez si le nombre de connexions `idle in transaction` est croissant. Pour ce faire, surveillez la colonne `state` de la table `pg_stat_activity`. Vous pouvez identifier la source des connexions en exécutant une requête semblable à la suivante.
```
select client_addr, state, count(1) from pg_stat_activity
where state like 'idle in transaction%'
group by 1,2
order by 3 desc
```