# Client:ClientRead
El evento `Client:ClientRead` ocurre cuando Aurora PostgreSQL espera recibir datos del cliente.
**Topics**
+ [Versiones del motor admitidas](#apg-waits.clientread.context.supported)
+ [Contexto](#apg-waits.clientread.context)
+ [Causas probables del aumento de las esperas](#apg-waits.clientread.causes)
+ [Acciones](#apg-waits.clientread.actions)
## Versiones del motor admitidas
Esta información de eventos de espera se admite para Aurora PostgreSQL versión 10 y posterior.
## Contexto
Un clúster de base de datos de Aurora PostgreSQL espera recibir datos del cliente. El clúster de la base de datos de Aurora PostgreSQL tiene que recibir los datos del cliente antes de poder enviar más datos al cliente. El tiempo que el clúster 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 el clúster de la base de datos PostgreSQL de Aurora y el cliente. Una mayor latencia de red aumenta el tiempo necesario para que el clúster de la 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 al clúster de la base de datos de Aurora PostgreSQL.
**Excesivos viajes de ida y vuelta de la red**
Un gran número de viajes de ida y vuelta de la red entre el clúster de la base de datos de Aurora PostgreSQL y el cliente puede retrasar la transmisión de datos del cliente al clúster de la base de datos de Aurora PostgreSQL.
**Operación de copia grande**
Durante una operación de copia, los datos se transfieren desde el sistema de archivos del cliente al clúster de la base de datos de Aurora PostgreSQL. El envío de una gran cantidad de datos al clúster de la base de datos puede retrasar la transmisión de datos del cliente al clúster de la base de datos.
**Conexión de cliente inactivo**
Una conexión a una instancia de base de datos de Aurora PostgreSQL está inactiva en el estado de transacción y espera a que un cliente envíe más datos o emita un comando. Este estado puede resultar en 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**
+ [Coloque los clientes en la misma zona de disponibilidad y subred VPC que el clúster](#apg-waits.clientread.actions.az-vpc-subnet)
+ [Escale el cliente](#apg-waits.clientread.actions.scale-client)
+ [Utilizar las instancias de generación actual](#apg-waits.clientread.actions.db-instance-class)
+ [Aumentar el ancho de banda de la red](#apg-waits.clientread.actions.increase-network-bandwidth)
+ [Monitorear los máximos de rendimiento de la red](#apg-waits.clientread.actions.monitor-network-performance)
+ [Monitorear las transacciones en el estado “inactivo en la transacción”](#apg-waits.clientread.actions.check-idle-in-transaction)
### Coloque los clientes en la misma zona de disponibilidad y subred VPC que el clúster
Para reducir la latencia de la red y aumentar el rendimiento de la red, coloque los clientes en la misma zona de disponibilidad y subred de nube virtual privada (VPC) que el clúster de la base de datos de Aurora PostgreSQL. Asegúrese de que los clientes estén lo más cerca geográficamente posible del clúster de la base de datos.
### Escale 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 Amazon Aurora](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 el clúster 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 acerca de las métricas de CloudWatch, consulte [Métricas de Amazon CloudWatch para Amazon Aurora](Aurora.AuroraMonitoring.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
```