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 quand RDS pour PostgreSQL attend de recevoir des données du client.
**Topics**
+ [Versions de moteur prises en charge](#wait-event.clientread.context.supported)
+ [Contexte](#wait-event.clientread.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#wait-event.clientread.causes)
+ [Actions](#wait-event.clientread.actions)
## Versions de moteur prises en charge
Ces informations sur les événements d’attente sont prises en charge pour RDS pour PostgreSQL versions 10 et ultérieures.
## Contexte
Une instance de base de données RDS pour PostgreSQL attend de recevoir des données du client. L’instance de base de données RDS pour PostgreSQL doit recevoir les données du client avant de pouvoir envoyer plus de données au client. La période pendant laquelle l'instance 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 l’instance de base de données RDS pour PostgreSQL et le client. Une latence réseau plus élevée augmente le temps de réception des données du client par l'instance de base 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 sur le client peut retarder la transmission des données du client vers l’instance de base de données RDS pour PostgreSQL.
**Nombre excessif d’allers-retours réseau**
Un grand nombre d’allers-retours réseau entre l’instance de base de données RDS pour PostgreSQL et le client peut retarder la transmission des données du client vers l’instance de base de données RDS pour 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 l’instance de base de données RDS pour PostgreSQL. L'envoi d'une grande quantité de données à l'instance de base de données peut retarder la transmission des données du client vers l'instance de base de données.
**Connexion client inactive**
Quand un client se connecte à l’instance de base de données RDS pour PostgreSQL alors que son état est `idle in transaction`, l’instance de base de données peut attendre que le client envoie plus de données ou émette une commande. Une connexion dans ces conditions 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**
+ [Placement des clients dans la même zone de disponibilité et le même sous-réseau VPC que l'instance](#wait-event.clientread.actions.az-vpc-subnet)
+ [Procédez à la mise à l’échelle du client](#wait-event.clientread.actions.scale-client)
+ [Utilisez des instances de la génération actuelle](#wait-event.clientread.actions.db-instance-class)
+ [Augmentez la bande passante réseau](#wait-event.clientread.actions.increase-network-bandwidth)
+ [Surveillez les valeurs maximales des métriques de performances réseau](#wait-event.clientread.actions.monitor-network-performance)
+ [Surveillez les transactions dont l’état est « idle in transaction » (transaction inactive)](#wait-event.clientread.actions.check-idle-in-transaction)
### Placement des clients dans la même zone de disponibilité et le même sous-réseau VPC que l'instance
Pour réduire la latence réseau et augmenter le 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 l’instance de base de données RDS pour PostgreSQL. Veillez à ce que les clients soient géographiquement aussi proches que possible de l'instance de base de données.
### 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 ](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 l'instance 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 de plus amples informations, veuillez consulter [Types de classes d’instance de base de données](Concepts.DBInstanceClass.Types.md).
Pour plus d'informations sur CloudWatch les métriques, consultez[CloudWatch Métriques Amazon pour Amazon RDS](rds-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
```