Solución de problemas de carga de trabajo de bases de datos Aurora MySQL - Amazon Aurora
Métricas de host de la instanciaMétricas de bases de datos

Solución de problemas de carga de trabajo de bases de datos Aurora MySQL

La carga de trabajo de la base de datos se puede ver como lecturas y escrituras. Si comprende cuál es la carga de trabajo “normal” de una base de datos, podrá ajustar las consultas y el servidor de base de datos para adaptarlos a la demanda a medida que esta vaya cambiando. Existen varios motivos por los que el rendimiento puede cambiar, por lo que el primer paso es entender qué ha cambiado.

  • ¿Se ha realizado una actualización de una versión principal o secundaria?

    Una actualización de la versión principal incluye cambios en el código del motor, especialmente en el optimizador, que pueden cambiar el plan de ejecución de las consultas. Al actualizar las versiones de la base de datos, especialmente las versiones principales, es muy importante analizar la carga de trabajo de la base de datos y ajustarla en consecuencia. Este ajuste puede implicar optimizar y reescribir las consultas o agregar y actualizar la configuración de los parámetros, en función de los resultados de las pruebas. Entender qué es lo que está causando ese efecto le permitirá empezar a centrarse en esa área específica.

    Para obtener más información, consulte What is new in MySQL 8.0 y Server and status variables and options added, deprecated, or removed in MySQL 8.0 en la documentación de MySQL y Comparación entre Aurora MySQL versión 2 y Aurora MySQL versión  3.

  • ¿Se ha producido un aumento en el procesamiento de datos (número de filas)?

  • ¿Hay más consultas ejecutándose simultáneamente?

  • ¿Hay cambios en el esquema o en la base de datos?

  • ¿Se han producido errores o correcciones en el código?

Contenido

Métricas de host de la instancia

Supervise las métricas del host de la instancia, como la actividad de la CPU, la memoria y la red, para saber si se ha producido un cambio en la carga de trabajo. Existen dos conceptos principales para entender los cambios en la carga de trabajo:

  • Utilización: el uso de un dispositivo, como la CPU o el disco. Puede basarse en el tiempo o en la capacidad.

    • Basado en el tiempo: la cantidad de tiempo que un recurso está ocupado durante un período de observación determinado.

    • Basado en la capacidad: la cantidad de rendimiento que puede ofrecer un sistema o componente, expresado como porcentaje de su capacidad.

  • Saturación: hasta qué punto se requiere más trabajo de un recurso del que puede procesar. Cuando el uso basado en la capacidad alcanza el 100 %, el trabajo adicional no se puede procesar y debe ponerse en cola.

Uso de la CPU

Puede utilizar las siguientes herramientas para identificar el uso y la saturación de la CPU:

  • CloudWatch proporciona la métrica CPUUtilization. Si llega al 100 %, la instancia está saturada. Sin embargo, las métricas de CloudWatch tienen un promedio de más de 1 minuto y carecen de granularidad.

    Para obtener más información sobre las métricas de CloudWatch, consulte Métricas de nivel de instancia para Amazon Aurora.

  • El monitoreo mejorado proporciona métricas que devuelve el comando del sistema operativo top. Muestra los promedios de carga y los siguientes estados de la CPU, con una granularidad de 1 segundo:

    • Idle (%) = tiempo de inactividad

    • IRQ (%) = interrupciones de software

    • Nice (%) = tiempo nice para los procesos con una prioridad niced.

    • Steal (%) = tiempo dedicado a atender a otros inquilinos (relacionado con la virtualización)

    • System (%) = tiempo del sistema

    • User (%) = tiempo de usuario

    • Wait (%) = espera de E/S

    Para obtener más información acerca de las métricas de Supervisión mejorada, consulte Métricas del sistema operativo para Aurora.

Uso de memoria

Si al sistema le falta memoria y el consumo de recursos está a punto de saturarse, debería haber un alto grado de errores de análisis de páginas, paginación, intercambio y falta de memoria.

Puede utilizar las siguientes herramientas para identificar el uso y la saturación de la memoria:

CloudWatch proporciona la métrica FreeableMemory, que muestra la cantidad de memoria que se puede recuperar vaciando algunas de las cachés del sistema operativo y la memoria libre actual.

Para obtener más información sobre las métricas de CloudWatch, consulte Métricas de nivel de instancia para Amazon Aurora.

El monitoreo mejorado proporciona las siguientes métricas que pueden ayudarle a identificar los problemas de uso de la memoria:

  • Buffers (KB): la cantidad de memoria utilizada para almacenar en búfer solicitudes de E/S antes de escribir en el dispositivo de almacenamiento, en kilobytes.

  • Cached (KB): la cantidad de memoria utilizada para almacenar en la caché las E/S basadas en el sistema de archivos.

  • Free (KB): la cantidad de memoria no asignada, en kilobytes.

  • Swap: en caché, gratis y total.

Por ejemplo, si ve que la instancia de base de datos utiliza memoria Swap, la cantidad total de memoria para su carga de trabajo es mayor de la que la instancia tiene disponible actualmente. Le recomendamos aumentar el tamaño de la instancia de base de datos o ajustar la carga de trabajo para utilizar menos memoria.

Para obtener más información acerca de las métricas de Supervisión mejorada, consulte Métricas del sistema operativo para Aurora.

Para obtener información más detallada sobre el uso de Performance Schema y el esquema de sys para determinar qué conexiones y componentes utilizan memoria, consulte Solución de problemas de uso de memoria de bases de datos Aurora MySQL.

Network throughput

CloudWatch proporciona las siguientes métricas para el rendimiento total de la red, todas con un promedio de más de 1 minuto:

  • NetworkReceiveThroughput: la cantidad de rendimiento de red que recibe de los clientes cada instancia en el clúster de base de datos de Aurora.

  • NetworkTransmitThroughput: el rendimiento de red que envía a los clientes cada instancia del clúster de base de datos de Aurora.

  • NetworkThroughput: el rendimiento de red que recibe de los clientes y transmite a ellos cada instancia en el clúster de base de datos de Aurora.

  • StorageNetworkReceiveThroughput: el rendimiento de red que se recibe del subsistema de almacenamiento de Aurora por cada instancia del clúster de base de datos.

  • StorageNetworkTransmitThroughput: el rendimiento de red que se envía al subsistema de almacenamiento de Aurora por cada instancia en el clúster de base de datos de Aurora.

  • StorageNetworkThroughput: el rendimiento de red que se recibe del subsistema de almacenamiento de Aurora y se envía a este por cada instancia en el clúster de base de datos de Aurora.

Para obtener más información sobre las métricas de CloudWatch, consulte Métricas de nivel de instancia para Amazon Aurora.

El monitoreo mejorado proporciona los gráficos de network recibidos (RX) y transmitidos (TX), con una granularidad de hasta 1 segundo.

Para obtener más información acerca de las métricas de Supervisión mejorada, consulte Métricas del sistema operativo para Aurora.

Métricas de bases de datos

Examine las siguientes métricas de CloudWatch para ver si hay cambios en la carga de trabajo:

  • BlockedTransactions: número medio de transacciones de la base de datos que se bloquean cada segundo.

  • BufferCacheHitRatio: porcentaje de solicitudes que se responden desde la caché de búfer.

  • CommitThroughput: número medio de operaciones de confirmación por segundo.

  • DatabaseConnections: número de conexiones de red de cliente a la instancia de base de datos.

  • Deadlocks: número medio de interbloqueos en la base de datos por segundo.

  • DMLThroughput: número medio de inserciones, actualizaciones y eliminaciones por segundo.

  • ResultSetCacheHitRatio: porcentaje de solicitudes que se responden desde la caché de consultas.

  • RollbackSegmentHistoryListLength: registros redo que registran transacciones confirmadas con registros marcados para su eliminación.

  • RowLockTime: tiempo total dedicado a adquirir bloqueos de fila para tablas de InnoDB.

  • SelectThroughput: número medio de consultas de selección por segundo.

Para obtener más información sobre las métricas de CloudWatch, consulte Métricas de nivel de instancia para Amazon Aurora.

Tenga en cuenta las siguientes preguntas al examinar la carga de trabajo:

  1. ¿Se han producido cambios recientes en la clase de la instancia de base de datos, por ejemplo, se ha reducido el tamaño de la instancia de 8xlarge a 4xlarge o se ha cambiado de db.r5 a db.r6?

  2. ¿Puede crear un clon y reproducir el problema o solo ocurre en esa instancia?

  3. ¿Se agotan los recursos del servidor? ¿La CPU o la memoria sufren un gran agotamiento? En caso afirmativo, esto podría significar que se requiere hardware adicional.

  4. ¿Una o más consultas están tardando más tiempo?

  5. ¿Los cambios se deben a una actualización, especialmente a una actualización de una versión principal? En caso afirmativo, compare las métricas previas y posteriores a la actualización.

  6. ¿Hay cambios en la cantidad de instancias de base de datos de lector?

  7. ¿Ha habilitado el registro general, de auditoría o binario? Para obtener más información, consulte Registro de bases de datos Aurora MySQL.

  8. ¿Ha habilitado, deshabilitado o cambiado el uso de la replicación de registros binarios (binlog)?

  9. ¿Hay transacciones de larga duración que contengan un gran número de bloqueos de filas? Examine la longitud de la lista de historial (HLL) de InnoDB para ver si hay indicios de transacciones de larga duración.

    Para obtener más información, consulte La longitud de la lista de historial de InnoDB ha aumentado de forma significativa y la entrada del blog Why is my SELECT query running slowly on my Amazon Aurora MySQL DB clúster?

    1. Si una HLL de gran tamaño se debe a una transacción de escritura, eso significa que los registros UNDO se están acumulando (no se limpian con regularidad). En una transacción de escritura de gran tamaño, esta acumulación puede aumentar rápidamente. En MySQL, UNDO se almacena en el espacio de tabla SYSTEM. El espacio de tabla SYSTEM no se puede reducir. El registro UNDO puede hacer que el espacio de tabla SYSTEM aumente varios GB o incluso TB. Tras la purga, libere el espacio asignado realizando una copia de seguridad lógica (volcado) de los datos y, a continuación, importe el volcado a una nueva instancia de base de datos.

    2. Si una HLL de gran tamaño se debe a una transacción de lectura (consulta de larga duración), eso puede significar que la consulta utiliza una gran cantidad de espacio temporal. Reinicie para liberar el espacio temporal. Examine las métricas de la base de datos de Información de rendimiento para ver si se ha producido algún cambio en la sección Temp, por ejemplo, created_tmp_tables. Para obtener más información, consulte Monitoreo de la carga de base de datos con Performance Insights en Amazon Aurora.

  10. ¿Se pueden dividir las transacciones de larga duración en otras más pequeñas que modifiquen menos filas?

  11. ¿Se han producido cambios en las transacciones bloqueadas o han aumentado los interbloqueos? Examine las métricas de base de datos de Información de rendimiento para detectar cualquier cambio en las variables de estado en la sección Locks, como innodb_row_lock_time, innodb_row_lock_waits y innodb_dead_locks. Use intervalos de 1 o 5 minutos.

  12. ¿Hay un aumento de los eventos de espera? Examine los eventos de espera y los tipos de espera de Información de rendimiento a intervalos de 1 o 5 minutos. Analice los principales eventos de espera y compruebe si están relacionados con los cambios en la carga de trabajo o con la contención de la base de datos. Por ejemplo, buf_pool mutex indica una contención del grupo de búferes. Para obtener más información, consulte Ajuste de Aurora MySQL con eventos de espera.