El rendimiento de E/S es vital para las bases de datos MySQL. Los datos se leen y escriben en el disco en numerosos lugares. Registros de rehacer, espacios de tabla, registros binarios y de retransmisión. Con un aumento en el uso de unidades de estado sólido, el rendimiento de E/S ha aumentado significativamente, lo que permite a los usuarios impulsar sus bases de datos aún más rápido, pero incluso entonces, la E/S puede convertirse en un cuello de botella y un factor limitante del rendimiento de toda la base de datos. En esta publicación de blog, veremos las cosas que desea verificar si nota que su rendimiento de E/S es alto en su instancia de MySQL.
¿Qué significa una utilización de E/S "alta"? En resumen, si el rendimiento de su base de datos se ve afectado, es alto. Por lo general, notará que las escrituras se ralentizan en la base de datos. También se manifestará claramente como una espera alta de E/S en su sistema. Sin embargo, tenga en cuenta que en los hosts con 32 o más núcleos de CPU, incluso si un núcleo muestra una espera de E/S del 100 %, es posible que no lo note en una vista agregada; representará solo 1/32 de la carga total. . Parece que no afecta, pero de hecho, alguna operación de E/S de subproceso único está saturando su CPU y alguna aplicación está esperando que finalice esa actividad de E/S.
Digamos que notamos un aumento en la actividad de E/S, solo como en la captura de pantalla anterior. ¿Qué mirar si notó una alta actividad de E/S? Primero, verifique la lista de procesos en el sistema. ¿Cuál es responsable de una espera de E/S? Puede usar iotop para comprobar que:
En nuestro caso está bastante claro que es MySQL el responsable de La mayor parte. Deberíamos comenzar con la verificación más simple:¿qué se está ejecutando exactamente en MySQL en este momento?
Podemos ver que hay actividad de replicación en nuestro esclavo. ¿Qué le está pasando al maestro?
Podemos ver claramente que se está ejecutando un trabajo de carga por lotes. Este tipo de finaliza nuestro viaje aquí, ya que logramos identificar el problema con bastante facilidad.
Hay otros casos, sin embargo, que pueden no ser tan fáciles de entender y rastrear. MySQL viene con algo de instrumentación, cuyo objetivo es ayudar a comprender la actividad de E/S en el sistema. Como mencionamos, las E/S se pueden generar en numerosos lugares del sistema. Las escrituras son las más claras, pero es posible que también tengamos tablas temporales en el disco; es bueno ver si sus consultas usan dichas tablas o no.
Si tiene habilitado performance_schema, una forma de verificar qué archivos son responsables de la carga de E/S puede ser consultar 'table_io_waits_summary_by_table':
*************************** 13. row ***************************
FILE_NAME: /tmp/MYfd=68
EVENT_NAME: wait/io/file/sql/io_cache
OBJECT_INSTANCE_BEGIN: 140332382801216
COUNT_STAR: 17208
SUM_TIMER_WAIT: 23332563327000
MIN_TIMER_WAIT: 1596000
AVG_TIMER_WAIT: 1355913500
MAX_TIMER_WAIT: 389600380500
COUNT_READ: 10888
SUM_TIMER_READ: 20108066180000
MIN_TIMER_READ: 2798750
AVG_TIMER_READ: 1846809750
MAX_TIMER_READ: 389600380500
SUM_NUMBER_OF_BYTES_READ: 377372793
COUNT_WRITE: 6318
SUM_TIMER_WRITE: 3224434875000
MIN_TIMER_WRITE: 16699500
AVG_TIMER_WRITE: 510356750
MAX_TIMER_WRITE: 223219960500
SUM_NUMBER_OF_BYTES_WRITE: 414000000
COUNT_MISC: 2
SUM_TIMER_MISC: 62272000
MIN_TIMER_MISC: 1596000
AVG_TIMER_MISC: 31136000
MAX_TIMER_MISC: 60676000
*************************** 14. row ***************************
FILE_NAME: /tmp/Innodb Merge Temp File
EVENT_NAME: wait/io/file/innodb/innodb_temp_file
OBJECT_INSTANCE_BEGIN: 140332382780800
COUNT_STAR: 1128
SUM_TIMER_WAIT: 16465339114500
MIN_TIMER_WAIT: 8490250
AVG_TIMER_WAIT: 14596931750
MAX_TIMER_WAIT: 583930037500
COUNT_READ: 540
SUM_TIMER_READ: 15103082275500
MIN_TIMER_READ: 111663250
AVG_TIMER_READ: 27968670750
MAX_TIMER_READ: 583930037500
SUM_NUMBER_OF_BYTES_READ: 566231040
COUNT_WRITE: 540
SUM_TIMER_WRITE: 1234847420750
MIN_TIMER_WRITE: 286167500
AVG_TIMER_WRITE: 2286754250
MAX_TIMER_WRITE: 223758795000
SUM_NUMBER_OF_BYTES_WRITE: 566231040
COUNT_MISC: 48
SUM_TIMER_MISC: 127409418250
MIN_TIMER_MISC: 8490250
AVG_TIMER_MISC: 2654362750
MAX_TIMER_MISC: 43409881500Como puede ver arriba, también muestra tablas temporales que están en uso.
Para verificar dos veces si una consulta en particular usa una tabla temporal, puede usar EXPLICAR PARA LA CONEXIÓN:
mysql> EXPLAIN FOR CONNECTION 3111\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sbtest1
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 986400
filtered: 100.00
Extra: Using temporary; Using filesort
1 row in set (0.16 sec)En el ejemplo anterior, se usa una tabla temporal para ordenar archivos.
Otra forma de ponerse al día con la actividad del disco es, si usa Percona Server para MySQL, habilitar la verbosidad completa del registro lento:
mysql> SET GLOBAL log_slow_verbosity='full';
Query OK, 0 rows affected (0.00 sec)Luego, en el registro lento, puede ver entradas como esta:
# Time: 2020-01-31T12:05:29.190549Z
# [email protected]: root[root] @ localhost [] Id: 12395
# Schema: Last_errno: 0 Killed: 0
# Query_time: 43.260389 Lock_time: 0.031185 Rows_sent: 1000000 Rows_examined: 2000000 Rows_affected: 0
# Bytes_sent: 197889110 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# InnoDB_trx_id: 0
# Full_scan: Yes Full_join: No Tmp_table: No Tmp_table_on_disk: No
# Filesort: Yes Filesort_on_disk: Yes Merge_passes: 141
# InnoDB_IO_r_ops: 9476 InnoDB_IO_r_bytes: 155254784 InnoDB_IO_r_wait: 5.304944
# InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000
# InnoDB_pages_distinct: 8191
SET timestamp=1580472285;
SELECT * FROM sbtest.sbtest1 ORDER BY RAND();Como puede ver, puede saber si había una tabla temporal en el disco o si los datos estaban ordenados en el disco. También puede comprobar el número de operaciones de E/S y la cantidad de datos a los que se accede.
Esperamos que esta publicación de blog lo ayude a comprender la actividad de E/S en el sistema y le permita administrarlo mejor.
