La E/S alta en una instancia de ApsaraDB RDS for MySQL suele deberse a cinco causas principales: alto rendimiento, tablas temporales, lecturas de datos fríos, instrucciones DDL y escrituras de registros binarios (binary log) en transacciones grandes. Use esta guía para identificar la causa y aplicar la solución correspondiente.
Resumen de las causas comunes
|
Causa |
Dónde buscarla en la consola |
Indicador clave |
|
Alto rendimiento |
Autonomy Service > Dashboard > Performance Trends |
Carga de lectura y escritura |
|
Tablas temporales |
Autonomy Service > Dashboard > Performance Trends |
Tamaño del directorio |
|
Lecturas de datos fríos |
Autonomy Service > Dashboard > Performance Trends |
Tasa de aciertos del buffer pool |
|
Instrucciones DDL |
Monitoring and Alerts > Standard Monitoring > Standard View |
Uso de disco e IOPS |
|
Escrituras de registros binarios en transacciones grandes |
— |
Aumento repentino y considerable en el volumen del registro binario |
Cómo InnoDB gestiona la E/S
InnoDB usa un sistema de E/S independiente para leer y escribir páginas de datos. Cuando una instrucción SQL solicita una página de datos que no está en el buffer pool, InnoDB la lee del disco mediante E/S síncrona. Los hilos en segundo plano usan E/S asíncrona para vaciar las páginas modificadas (dirty pages) al disco.
Además de la E/S de los archivos de datos, otras operaciones incrementan significativamente la E/S: las escrituras de redo log, undo log y binary log, la ordenación de tablas temporales y la reconstrucción de tablespaces por instrucciones DDL. Cada una de las cinco causas descritas a continuación se relaciona con uno o más de estos mecanismos.
Solución de problemas de E/S alta por alto rendimiento
Síntoma
Las operaciones frecuentes de UPDATE, DELETE e INSERT sobre tablas con muchos índices o campos grandes elevan la E/S de dos maneras. Primero, RDS carga las páginas de datos en el buffer pool. Después, los hilos en segundo plano escriben las páginas modificadas resultantes en el disco. La presión combinada de lectura y escritura aumenta la E/S.
Para comprobarlo, vaya a Autonomy Service > Dashboard en el panel de navegación izquierdo de la consola de ApsaraDB RDS, abra la pestaña Performance Trends y revise las métricas de carga de lectura y escritura.
Solución
Reduzca la frecuencia de lectura y escritura, actualice el tipo de instancia o ajuste los parámetros que controlan el vaciado de páginas modificadas.
|
Parámetro |
Valor predeterminado |
Descripción |
|
|
75 |
Porcentaje máximo de páginas modificadas permitido en el buffer pool |
|
|
0 (deshabilitado) |
Límite inferior de páginas modificadas; al superarlo, RDS vacía proactivamente las páginas modificadas para mantener espacio disponible en el buffer pool |
|
|
20000 |
Número máximo de operaciones de E/S por segundo available para las tareas en segundo plano de InnoDB; controla la velocidad de vaciado de páginas modificadas y las escrituras en el buffer pool |
|
|
40000 |
Límite superior de operaciones de E/S por segundo; solo surte efecto cuando el vaciado de páginas modificadas se retrasa y debe ser mayor que |
El valor de innodb_max_dirty_pages_pct_lwm debe ser menor o igual que innodb_max_dirty_pages_pct. Si establece un valor mayor, RDS lo restablece automáticamente al valor de innodb_max_dirty_pages_pct.
Solución de problemas de E/S alta por tablas temporales
Síntoma
Las instrucciones SQL lentas que implican ordenación o deduplicación hacen que InnoDB cree tablas temporales grandes en el disco. Tanto la creación como la escritura en estas tablas temporales aumentan la E/S. Un tamaño elevado del directorio tmp es un indicador confiable de este problema.
Para comprobarlo, vaya a Autonomy Service > Dashboard en el panel de navegación izquierdo de la consola de ApsaraDB RDS, abra la pestaña Performance Trends y revise el tamaño del directorio tmp.
Solución
Optimice las instrucciones SQL que generan tablas temporales. Database Autonomy Service (DAS) incluye optimización de SQL integrada para ayudarle a identificar y corregir consultas lentas. Para obtener más información, consulte SQL optimization.
Solución de problemas de E/S alta por lecturas de datos fríos
Síntoma
Cuando las páginas de datos que requiere una consulta o una instrucción DML no están en el buffer pool, InnoDB las lee del disco. Una tasa de aciertos baja en el buffer pool indica que la mayoría de las solicitudes van al disco, lo cual incrementa notablemente la E/S.
Para comprobarlo, vaya a Autonomy Service > Dashboard en el panel de navegación izquierdo de la consola de ApsaraDB RDS, abra la pestaña Performance Trends y revise la tasa de aciertos del buffer pool.
Solución
Rediseñe su estrategia de caché según los patrones de acceso de su carga de trabajo. Como alternativa, actualice su instancia de RDS.
Solución de problemas de E/S alta por instrucciones DDL
Síntoma
Las instrucciones DDL desencadenan una reconstrucción completa del tablespace. InnoDB examina cada fila, crea índices de ordenación y vacía las páginas modificadas correspondientes a la nueva estructura de la tabla. Eliminar tablas grandes también genera una cantidad considerable de E/S. Estas operaciones provocan picos pronunciados tanto en el uso de disco como en las IOPS.
Para comprobarlo, vaya a Monitoring and Alerts en el panel de navegación izquierdo de la consola de ApsaraDB RDS, haga clic en Standard View dentro de la pestaña Standard Monitoring y revise el uso de disco y las IOPS.
Solución
Use la función Purge Large File Asynchronously para eliminar archivos grandes sin bloquear la E/S. Esta función forma parte de AliSQL, la rama de MySQL de Alibaba Cloud. Para obtener más información, consulte Purge Large File Asynchronously.
Solución de problemas de E/S alta por escrituras de registros binarios en transacciones grandes
Síntoma
InnoDB escribe en los archivos de registro binario únicamente al confirmar la transacción. Una sola transacción grande, por ejemplo, una instrucción DELETE que elimina una gran cantidad de filas, puede generar varias decenas de GB de datos de registro binario. Vaciar ese volumen al disco de un solo golpe provoca un pico abrupto de E/S.
Solución
Divida las transacciones grandes en lotes más pequeños. Las confirmaciones más pequeñas distribuyen los vaciados del registro binario a lo largo del tiempo, reducen las escrituras de páginas modificadas en el disco y evitan el estallido de E/S que produce una única confirmación grande.