# Client:ClientRead
El evento `Client:ClientRead` ocurre cuando RDS para PostgreSQL espera recibir datos del cliente.
**Topics**
+ [Versiones del motor admitidas](#wait-event.clientread.context.supported)
+ [Contexto](#wait-event.clientread.context)
+ [Causas probables del aumento de las esperas](#wait-event.clientread.causes)
+ [Acciones](#wait-event.clientread.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con RDS para PostgreSQL versión 10 y posteriores.
## Contexto
Una instancia de base de datos de RDS para PostgreSQL espera recibir datos del cliente. La instancia de la base de datos de RDS para PostgreSQL tiene que recibir los datos del cliente antes de poder enviar más datos al cliente. El tiempo que la instancia espera antes de recibir los datos del cliente es un evento `Client:ClientRead`.
## Causas probables del aumento de las esperas
Las causas más comunes para que el evento `Client:ClientRead` aparezca en el máximo de esperas son las siguientes:
**Aumento de la latencia de la red**
Puede haber un aumento de la latencia de la red entre la instancia de la base de datos de RDS para PostgreSQL y el cliente. Una mayor latencia de la red aumenta el tiempo necesario para que la instancia de base de datos reciba los datos del cliente.
**Aumento de la carga en el cliente**
Puede haber presión de la CPU o saturación de la red en el cliente. Un aumento de la carga en el cliente puede retrasar la transmisión de datos desde el cliente a la instancia de la base de datos de RDS para PostgreSQL.
**Excesivos viajes de ida y vuelta de la red**
Un gran número de viajes de ida y vuelta de la red entre la instancia de la base de datos de RDS para PostgreSQL y el cliente puede retrasar la transmisión de datos del cliente a la instancia de la base de datos de RDS para PostgreSQL.
**Operación de copia grande**
Durante una operación de copia, los datos se transfieren desde el sistema de archivos del cliente a la instancia de la base de datos de RDS para PostgreSQL. El envío de una gran cantidad de datos a la instancia de la base de datos puede retrasar la transmisión de datos del cliente a la instancia de la base de datos.
**Conexión de cliente inactivo**
Cuando un cliente se conecta a la instancia de la base de datos de RDS para PostgreSQL en un estado `idle in transaction`, la instancia de la base de datos puede esperar a que el cliente envíe más datos o emita un comando. Una conexión en este estado puede conducir a un aumento de eventos `Client:ClientRead`.
**PgBouncer se utiliza para la agrupación de conexiones**
PgBouncer tiene un ajuste de configuración de red de bajo nivel llamado `pkt_buf`, que se establece en 4.096 de forma predeterminada. Si la carga de trabajo envía paquetes de consulta de más de 4096 bytes a través de PgBouncer, recomendamos aumentar la configuración de `pkt_buf` a 8192. Si la nueva configuración no disminuye el número de eventos `Client:ClientRead`, recomendamos aumentar la configuración de `pkt_buf` a valores mayores, como 16 384 o 32 768. Si el texto de la consulta es grande, el ajuste más grande puede ser particularmente útil.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Colocar los clientes en la misma zona de disponibilidad y subred VPC que el evento de espera](#wait-event.clientread.actions.az-vpc-subnet)
+ [Escalar el cliente](#wait-event.clientread.actions.scale-client)
+ [Utilizar las instancias de generación actual](#wait-event.clientread.actions.db-instance-class)
+ [Aumentar el ancho de banda de la red](#wait-event.clientread.actions.increase-network-bandwidth)
+ [Monitorear los máximos de rendimiento de la red](#wait-event.clientread.actions.monitor-network-performance)
+ [Monitorear las transacciones en el estado “inactivo en la transacción”](#wait-event.clientread.actions.check-idle-in-transaction)
### Colocar los clientes en la misma zona de disponibilidad y subred VPC que el evento de espera
Para reducir la latencia de la red y aumentar su rendimiento, coloque los clientes en la misma zona de disponibilidad y subred de nube privada virtual (VPC) que la instancia de la base de datos de RDS para PostgreSQL. Asegúrese de que los clientes estén lo más cerca posible desde el punto de vista geográfico de la instancia de la base de datos.
### Escalar el cliente
Con Amazon CloudWatch u otras métricas del anfitrión, determine si su cliente está actualmente limitado por la CPU o el ancho de banda de la red, o ambos. Si el cliente está restringido, escale su cliente en forma adecuada.
### Utilizar las instancias de generación actual
En algunos casos, es posible que no utilice una clase de instancia de base de datos que admita tramas gigantes. Si ejecuta la aplicación en Amazon EC2, considere la posibilidad de utilizar una instancia de generación actual para el cliente. Además, configure la unidad de transmisión máxima (MTU) en el sistema operativo del cliente. Esta técnica podría reducir el número de viajes de ida y vuelta de la red y aumentar el rendimiento de la red. Para obtener más información, consulte [Tramas gigantes (MTU 9001)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) en la *Guía del usuario de Amazon EC2*.
Para obtener información acerca de las clases de instancia de base de datos, consulte [Clases de instancia de base de datos de ](Concepts.DBInstanceClass.md). Para determinar la clase de instancia de base de datos que equivale a un tipo de instancia de Amazon EC2, coloque `db.` antes del nombre del tipo de instancia de Amazon EC2. Por ejemplo, la instancia de Amazon EC2 `r5.8xlarge` equivale a la clase de instancia de base de datos `db.r5.8xlarge`.
### Aumentar el ancho de banda de la red
Utilice las métricas de Amazon CloudWatch de `NetworkReceiveThroughput` y `NetworkTransmitThroughput` para monitorear el tráfico de red entrante y saliente en la instancia de la base de datos. Estas métricas pueden ayudarle a determinar si el ancho de banda de la red es suficiente para su carga de trabajo.
Si el ancho de banda de su red no es suficiente, auméntelo. Si el cliente de AWS o la instancia de base de datos alcanza los límites del ancho de banda de la red, la única forma de aumentar el ancho de banda es aumentar el tamaño de la instancia de base de datos. Para obtener más información, consulte [Tipos de clase de instancia de base de datos](Concepts.DBInstanceClass.Types.md).
Para obtener más información acerca de las métricas de CloudWatch, consulte [Métricas de Amazon CloudWatch para Amazon RDS](rds-metrics.md).
### Monitorear los máximos de rendimiento de la red
Si utiliza clientes de Amazon EC2, Amazon EC2 proporciona límites máximos para las métricas de rendimiento de la red, incluido el ancho de banda de red entrante y saliente agregado. También proporciona un seguimiento de la conexión para garantizar que los paquetes se devuelven como se espera y el acceso a los servicios de enlace local para servicios como el sistema de nombres de dominio (DNS). Para monitorear estos máximos, utilice un controlador de red mejorado actual y monitoree el rendimiento de la red para su cliente.
Para obtener más información, consulte [Monitorear el rendimiento de la red de la instancia de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) en la *Guía del usuario de Amazon EC2* y [Monitorear el rendimiento de la red de la instancia de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitoring-network-performance-ena.html) en la *Guía del usuario de Amazon EC2*.
### Monitorear las transacciones en el estado “inactivo en la transacción”
Verifique si tiene un número creciente de conexiones `idle in transaction`. Para ello, monitoree la columna `state` en la tabla `pg_stat_activity`. Es posible que pueda identificar el origen de la conexión si ejecuta una consulta similar a la siguiente.
```
select client_addr, state, count(1) from pg_stat_activity
where state like 'idle in transaction%'
group by 1,2
order by 3 desc
```