Les performances d'E/S sont vitales pour les bases de données MySQL. Les données sont lues et écrites sur le disque à de nombreux endroits. Refaire les journaux, les espaces de table, les journaux binaires et de relais. Avec une augmentation de l'utilisation des disques SSD, les performances d'E/S ont considérablement augmenté, permettant aux utilisateurs de pousser leurs bases de données encore plus rapidement, mais même dans ce cas, les E/S peuvent devenir un goulot d'étranglement et un facteur limitant les performances de l'ensemble de la base de données. Dans cet article de blog, nous examinerons les éléments que vous souhaitez vérifier si vous remarquez que vos performances d'E/S sont élevées sur votre instance MySQL.
Que signifie une utilisation d'E/S "élevée" ? Bref, si les performances de votre base de données en sont affectées, elles sont élevées. En règle générale, vous le remarquerez lorsque les écritures ralentissent dans la base de données. Cela se manifestera également clairement par une attente d'E / S élevée sur votre système. Veuillez garder à l'esprit, cependant, que sur les hôtes avec 32 cœurs de processeur et plus, même si un cœur affiche 100 % d'attente d'E/S, vous ne le remarquerez peut-être pas sur une vue agrégée - cela ne représentera que 1/32 de la charge totale . Cela ne semble pas avoir d'impact, mais en fait, certaines opérations d'E/S monothread saturent votre processeur et certaines applications attendent que cette activité d'E/S se termine.
Disons que nous avons remarqué une augmentation de l'activité d'E/S, juste comme dans la capture d'écran ci-dessus. Que regarder si vous avez remarqué une activité d'E/S élevée ? Tout d'abord, vérifiez la liste des processus du système. Lequel est responsable d'une attente d'E/S ? Vous pouvez utiliser iotop pour vérifier que :
Dans notre cas, il est assez clair que c'est MySQL qui est responsable de la plus grande partie. Nous devrions commencer par la vérification la plus simple - qu'est-ce qui s'exécute exactement dans MySQL en ce moment ?
Nous pouvons voir qu'il y a une activité de réplication sur notre esclave. Qu'arrive-t-il au maître ?
Nous pouvons clairement voir qu'un travail de chargement par lots est en cours d'exécution. Cela met fin à notre voyage ici car nous avons réussi à identifier le problème assez facilement.
Il existe cependant d'autres cas qui peuvent ne pas être faciles à comprendre et à suivre. MySQL est livré avec une instrumentation destinée à aider à comprendre l'activité d'E/S dans le système. Comme nous l'avons mentionné, les E/S peuvent être générées à de nombreux endroits du système. Les écritures sont les plus claires, mais nous pouvons également avoir des tables temporaires sur disque - il est bon de voir si vos requêtes utilisent ou non de telles tables.
Si vous avez activé performance_schema, une façon de vérifier quels fichiers sont responsables de la charge d'E/S peut être d'interroger '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: 43409881500Comme vous pouvez le voir ci-dessus, il affiche également les tables temporaires en cours d'utilisation.
Pour revérifier si une requête particulière utilise une table temporaire, vous pouvez utiliser EXPLAIN FOR CONNECTION :
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)Dans l'exemple ci-dessus, une table temporaire est utilisée pour le tri de fichiers.
Une autre façon de rattraper l'activité du disque est, si vous utilisez Percona Server pour MySQL, d'activer la verbosité complète des journaux lents :
mysql> SET GLOBAL log_slow_verbosity='full';
Query OK, 0 rows affected (0.00 sec)Ensuite, dans le journal lent, vous pouvez voir des entrées comme celle-ci :
# 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();Comme vous pouvez le voir, vous pouvez savoir s'il y avait une table temporaire sur le disque ou si les données ont été triées sur le disque. Vous pouvez également vérifier le nombre d'opérations d'E/S et la quantité de données consultées.
Nous espérons que cet article de blog vous aidera à comprendre l'activité d'E/S dans le système et vous permettra de mieux la gérer.
