envío de datos - Amazon Aurora
Versiones del motor admitidasContextoCausas probables del aumento de las esperasAcciones

envío de datos

El estado del subproceso sending data indica que un subproceso está leyendo y filtrando filas de una consulta para determinar el conjunto de resultados correcto. El nombre puede dar lugar a confusión porque implica que el estado está transfiriendo datos en lugar de recopilar y preparar datos para enviarlos más adelante.

Versiones del motor admitidas

Esta información de estado de subproceso es compatible con las siguientes versiones:

  • Aurora MySQL versión 2, hasta la versión 2.09.2

Contexto

Muchos estados de subprocesos son de corta duración. Las operaciones que se producen durante sending data tienden a realizar un gran número de lecturas de disco o caché. Por consiguiente, sending data suele ser el estado que permanece más tiempo en ejecución a lo largo de la vida útil de una consulta determinada. Este estado aparece cuando Aurora MySQL hace lo siguiente:

  • Lectura y procesamiento de filas de una instrucción SELECT

  • Realización de un gran número de lecturas desde el disco o la memoria

  • Realización de una lectura completa de todos los datos de una consulta específica

  • Lectura de datos desde una tabla, un índice o el trabajo de un procedimiento almacenado

  • Clasificación, agrupación u ordenación de datos

Una vez que el estado sending data finaliza la preparación de los datos, el estado del subproceso writing to net indica la devolución de datos al cliente. Normalmente, writing to net solo se captura cuando el conjunto de resultados es muy grande o cuando la elevada latencia de red ralentiza la transferencia.

Causas probables del aumento de las esperas

La apariencia de sending data no indica un problema. Si el rendimiento es deficiente y ve instancias frecuentes de sending data, las causas más probables son las siguientes.

Consulta ineficiente

En la mayoría de los casos, la causa de este estado suele ser una consulta que no utiliza un índice adecuado para buscar el conjunto de resultados de una consulta específica. Por ejemplo, piense en una consulta que lee una tabla de 10 millones de registros para todos los pedidos realizados en California, donde la columna de estado no está indexada o está mal indexada. En este caso, el índice puede existir, pero el optimizador lo ignora debido a su baja cardinalidad.

Configuración de servidor poco óptima

Si aparecen varias consultas en el estado sending data, el servidor de base de datos podría estar mal configurado. Más específicamente, el servidor podría tener los problemas siguientes:

  • El servidor de base de datos no tiene suficiente capacidad informática: E/S de disco, tipo y velocidad de disco, CPU o número de CPU.

  • El servidor no tiene recursos asignados, como, por ejemplo, el grupo de búferes InnoDB para tablas InnoDB o el búfer de claves de las tablas MyIsam.

  • La configuración de memoria por subproceso, como, por ejemplo, sort_buffer, read_buffer, y join_buffer, consumen más RAM de la necesaria, lo que provoca que el servidor físico no tenga recursos de memoria.

Acciones

La consigna general radica en buscar consultas que devuelvan un gran número de filas verificando Performance Schema. Si las consultas de registro que no utilizan índices están activadas, también puede examinar los resultados de los registros lentos.

Activar Performance Schema si no está activado

Información sobre rendimiento informa de los estados de subprocesos solo si los instrumentos de Performance Schema no están activados. Cuando los instrumentos de Performance Schema están activados, Información sobre rendimiento informa de los eventos de espera en su lugar. Los instrumentos de Performance Schema proporcionan información adicional y mejores herramientas para investigar posibles problemas de rendimiento. Por lo tanto, se recomienda activar Performance Schema. Para obtener más información, consulte Descripción general de Performance Schema para Información de rendimiento en Aurora MySQL.

Examinar la configuración de memoria

Examine la configuración de memoria de los grupos de búferes principales. Asegúrese de que estos grupos tengan el tamaño adecuado para la carga de trabajo. Si la base de datos utiliza varias instancias de grupos de búferes, asegúrese de que no estén divididas en muchos grupos de búferes pequeños. Los subprocesos solo pueden utilizar un grupo de búferes a la vez.

Asegúrese de que los ajustes de memoria utilizados para cada subproceso que se indican a continuación tengan el tamaño correcto:

  • read_buffer

  • read_rnd_buffer

  • sort_buffer

  • join_buffer

  • binlog_cache

A menos que tenga un motivo específico para modificar la configuración, utilice los valores predeterminados.

Examinar los planes de explicación para el uso de índice

Para consultas en el estado del subproceso sending data, examine el plan para determinar si se utilizan los índices adecuados. Si una consulta no utiliza un índice útil, considere la posibilidad de agregar sugerencias como USE INDEX o FORCE INDEX. Las sugerencias pueden aumentar o disminuir considerablemente el tiempo de ejecución de una consulta, por lo que tenga cuidado antes de agregarlas.

Verificar el volumen de datos devueltos

Verifique las tablas que se están consultando y la cantidad de datos que contienen. ¿Se puede archivar alguno de estos datos? En muchos casos, la causa del tiempo de ejecución de consultas deficiente no es el plan de consultas, sino el volumen de datos que se debe procesar. Muchos desarrolladores son muy eficientes al agregar datos a una base de datos, pero rara vez consideran el ciclo de vida de los conjuntos de datos en las fases de diseño y desarrollo.

Busque consultas que tengan un buen rendimiento en bases de datos de bajo volumen pero que funcionen mal en el sistema actual. A veces, los desarrolladores que diseñan consultas específicas podrían no darse cuenta de que estas consultas están devolviendo 350 000 filas. Es posible que los desarrolladores hayan desarrollado las consultas en un entorno de menor volumen con conjuntos de datos más pequeños que los que tienen los entornos de producción.

Verificar problemas de concurrencia

Verifique si se están ejecutando varias consultas del mismo tipo al mismo tiempo. Algunas formas de consultas se ejecutan de forma eficiente cuando se ejecutan solas. Sin embargo, si se ejecutan formas similares de consulta de manera conjunta o en gran volumen, pueden provocar problemas de concurrencia. A menudo, estos problemas se producen cuando la base de datos utiliza tablas temporales para generar resultados. Un nivel de aislamiento de transacciones restrictivo también puede provocar problemas de concurrencia.

Si las tablas se leen y escriben simultáneamente, la base de datos podría estar utilizando bloqueos. Para ayudar a identificar periodos de bajo rendimiento, examine el uso de bases de datos mediante procesos por lotes a gran escala. Para ver los bloqueos y reversiones recientes, examine el resultado del comando SHOW ENGINE INNODB STATUS.

Verificar la estructura de las consultas

Verifique si las consultas capturadas de estos estados utilizan subconsultas. Este tipo de consulta a menudo genera un rendimiento deficiente porque la base de datos compila los resultados internamente y luego los sustituye de nuevo en la consulta para procesar datos. Este proceso es un paso adicional para la base de datos. En muchos casos, este paso puede provocar un rendimiento deficiente en condiciones de cargas altamente concurrentes.

Verifique también si sus consultas utilizan un gran número de cláusulas ORDER BY y GROUP BY. En estas operaciones, a menudo la base de datos debe formar primero todo el conjunto de datos en la memoria. A continuación, debe pedirlo o agruparlo de manera específica antes de devolverlo al cliente.