Hvad skal du kontrollere, hvis MySQL I/O-udnyttelsen er høj

I/O-ydeevnen er afgørende for MySQL-databaser. Data læses og skrives til disken adskillige steder. Redo logs, tablespaces, binære og relæ logs. Med en stigning i brugen af ​​solid state-drev er I/O-ydeevnen øget betydeligt, hvilket giver brugerne mulighed for at presse deres databaser endnu hurtigere, men selv da kan I/O blive en flaskehals og en begrænsende faktor for hele databasens ydeevne. I dette blogindlæg vil vi tage et kig på de ting, du vil tjekke, hvis du bemærker, at din I/O-ydelse er høj på din MySQL-instans.

Hvad betyder "Høj" I/O-udnyttelse? Kort sagt, hvis ydeevnen af ​​din database påvirkes af det, er den høj. Typisk vil du bemærke det, som skriver, der går langsommere i databasen. Det vil også tydeligt vise sig som høj I/O-ventetid på dit system. Vær dog opmærksom på, at på værter med 32 eller flere CPU-kerner, selvom en kerne vil vise 100 % I/O-ventetid, vil du muligvis ikke bemærke det i en aggregeret visning - det vil kun repræsentere 1/32 af hele belastningen . Det ser ikke ud til at påvirke, men faktisk mætter nogle enkelttrådede I/O-operationer din CPU, og nogle applikationer venter på, at I/O-aktiviteten er færdig.

Lad os sige, at vi bemærkede en stigning i I/O-aktiviteten, bare som på skærmbilledet ovenfor. Hvad skal du se på, hvis du bemærkede høj I/O-aktivitet? Tjek først listen over processerne i systemet. Hvem er ansvarlig for en I/O-ventetid? Du kan bruge iotop til at kontrollere, at:

I vores tilfælde er det helt klart, at det er MySQL, der er ansvarlig for det meste af det. Vi bør starte med det enkleste tjek - hvad er det præcist, der kører i MySQL lige nu?

Vi kan se, at der er replikeringsaktivitet på vores slave. Hvad sker der med mesteren?

Vi kan tydeligt se, at et batch-indlæsningsjob kører. På den måde slutter vores rejse hertil, da det ganske nemt lykkedes os at lokalisere problemet.

Der er dog andre tilfælde, som måske ikke er så nemme at forstå og spore. MySQL kommer med noget instrumentering, som er beregnet til at hjælpe med at forstå I/O-aktiviteten i systemet. Som nævnt kan I/O genereres adskillige steder i systemet. Skrivninger er de mest klare, men vi kan også have midlertidige tabeller på disken - det er godt at se, om dine forespørgsler bruger sådanne tabeller eller ej.

Hvis du har performance_schema aktiveret, kan en måde at kontrollere, hvilke filer der er ansvarlige for I/O-belastningen være at forespørge 'table_io_waits_summary_by_table':

mysql> FORKLAR TIL FORBINDELSE 3111\G**************************** 1. række ****** ********************* id:1 select_type:SIMPLE tabel:sbtest1 partitioner:NULL type:ALLpossible_keys:NULL nøgle:NULL key_len:NULL ref:NULL rækker:986400 filtreret:100,00 Ekstra:Bruger midlertidig; Brug af filersorter1 række i sæt (0,16 sek.) 

mysql> SET GLOBAL log_slow_verbosity='full';Forespørgsel OK, 0 rækker påvirket (0,00 sek.) 

# Tid:2020-01-31T12:05:29.190549Z# [email protected]:root[root] @ localhost [] Id:12395# Skema:Last_errno:0 Dræbt:0# Forespørgselstid: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.0000 00