io/aurora_respond_to_client
El evento io/aurora_respond_to_client se produce cuando un subproceso está a la espera de devolver un conjunto de resultados a un cliente.
Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
-
Aurora MySQL versión 2
En las versiones anteriores a 2.07.7, 2.09.3 y 2.10.2, este evento de espera incluye por error el tiempo de inactividad.
Contexto
El evento io/aurora_respond_to_client indica que un subproceso está a la espera de devolver un conjunto de resultados a un cliente.
El procesamiento de consultas se ha completado y los resultados se devuelven al cliente de la aplicación. Sin embargo, dado que no hay suficiente ancho de banda de red en el clúster de base de datos, un subproceso está a la espera para devolver el conjunto de resultados.
Causas probables del aumento de las esperas
Cuando el evento io/aurora_respond_to_client aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
- Instancia de base de datos insuficiente para la carga de trabajo
-
La clase de instancia de base de datos que utiliza el clúster de base de datos no tiene el ancho de banda de red necesario para procesar la carga de trabajo de forma eficiente.
- Grandes conjuntos de resultados
-
Se ha producido un aumento en el tamaño del conjunto de resultados que se devuelve porque la consulta devuelve un mayor número de filas. El conjunto de resultados de gran tamaño consume más ancho de banda de red.
- Aumento de la carga en el cliente
-
Puede haber presión de la CPU, presión de memoria o saturación en el cliente. Un aumento de la carga en el cliente retrasa la recepción de los datos del clúster de la base de datos de Aurora MySQL.
- 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 de Aurora MySQL y el cliente. Una mayor latencia de la red aumenta el tiempo necesario para que el cliente reciba los datos.
Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
Temas
Identificar las sesiones y consultas que provocan los eventos
Puede utilizar Información sobre rendimiento para mostrar las consultas que bloqueó el evento de espera io/aurora_respond_to_client. Normalmente, las bases de datos con una carga de moderada a significativa tienen eventos de espera. Los eventos de espera pueden ser aceptables si el rendimiento es óptimo. Si el rendimiento no es óptimo, examine dónde pasa más tiempo la base de datos. Preste atención a los eventos de espera que contribuyen a la carga más alta y averigüe si puede optimizar la base de datos y la aplicación para reducirlos.
Para buscar consultas SQL responsables de cargas elevadas
Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/
. -
En el panel de navegación, seleccione Performance Insights.
-
Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
-
En el cuadro Database load (Carga de base de datos), elija Slice by wait (Corte por espera).
-
En la parte inferior de la página, elija Top SQL (SQL principal).
El gráfico enumera las consultas SQL responsables de la carga. Las que están en la parte superior de la lista son las más importantes. Para resolver un cuello de botella, céntrese en estas instrucciones.
Para obtener información general útil sobre la solución de problemas mediante Información sobre rendimiento, consulte la entrada de blog de AWS Database Analyze Amazon Aurora MySQL Workloads with Performance Insights
Escalar la clase de instancia de base de datos
Verifique el aumento del valor de las métricas de Amazon CloudWatch relacionadas con el rendimiento de la red, como, por ejemplo, NetworkReceiveThroughput y NetworkTransmitThroughput. Si se está llegando al límite de ancho de banda de red de la clase de instancia de base de datos, puede escalar la clase de instancia de base de datos que utiliza el clúster de base de datos modificando el clúster de base de datos. Una clase de instancia de base de datos con mayor ancho de banda de red devuelve datos a los clientes de forma más eficiente.
Para obtener más información acerca del monitoreo de métricas de Amazon CloudWatch, consulte Consulta de métricas en la consola de Amazon RDS. Para obtener información acerca de las clases de instancia de base de datos, consulte Clases de instancia de base de datos de Aurora. Para obtener más información acerca de la modificación de un clúster de bases de datos, consulte Modificación de un clúster de base de datos de Amazon Aurora.
Verificar la carga de trabajo en busca de resultados inesperados
Verifique la carga de trabajo en el clúster de base de datos y asegúrese de que no produzca resultados inesperados. Por ejemplo, puede haber consultas que devuelvan un mayor número de filas que el esperado. En este caso, puede utilizar las métricas de contador de Información sobre rendimiento, como, por ejemplo, Innodb_rows_read. Para obtener más información, consulte Métricas de contador de Información sobre rendimiento.
Distribuir la carga de trabajo con instancias de lector
Puede distribuir la carga de trabajo de solo lectura con réplicas de Aurora. Puede escalar horizontalmente con la incorporación de más réplicas de Aurora. Si lo hace, se pueden incrementar los límites de limitación controlada del ancho de banda de la red. Para obtener más información, consulte Clústeres de base de datos de Amazon Aurora.
Utilizar el modificador SQL_BUFFER_RESULT
Puede agregar el modificador SQL_BUFFER_RESULT a las instrucciones SELECT para forzar el resultado a una tabla temporal antes de que se devuelva al cliente. Este modificador puede ayudar con problemas de rendimiento cuando los bloqueos InnoDB no se liberan porque las consultas se encuentran en estado de espera io/aurora_respond_to_client. Para obtener más información, consulte SELECT Statement
