De I/O-prestaties zijn essentieel voor MySQL-databases. Op tal van plaatsen worden gegevens gelezen en naar de schijf geschreven. Voer logs, tablespaces, binaire logs en relay logs opnieuw uit. Met een toename van het gebruik van solid-state schijven zijn de I/O-prestaties aanzienlijk verbeterd, waardoor gebruikers hun databases nog sneller kunnen pushen, maar zelfs dan kan I/O een knelpunt en een beperkende factor worden voor de prestaties van de hele database. In deze blogpost bekijken we de dingen die u wilt controleren als u merkt dat uw I/O-prestaties hoog zijn op uw MySQL-instantie.
Wat betekent 'Hoog' I/O-gebruik? Kortom, als de prestaties van uw database erdoor worden beïnvloed, is deze hoog. Meestal zou je het merken als het schrijven in de database langzamer gaat. Het zal zich ook duidelijk manifesteren als een hoge I / O-wacht op uw systeem. Houd er echter rekening mee dat op hosts met 32 of meer CPU-kernen, zelfs als één kern 100% I/O-wacht laat zien, u dit misschien niet opmerkt in een geaggregeerde weergave - het vertegenwoordigt slechts 1/32 van de hele belasting . Het lijkt geen invloed te hebben, maar in feite verzadigt een single-threaded I/O-bewerking je CPU en een applicatie wacht tot die I/O-activiteit is voltooid.
Laten we zeggen dat we een toename in de I/O-activiteit hebben opgemerkt, alleen zoals in de bovenstaande schermafbeelding. Waar moet u op letten als u hoge I/O-activiteit opmerkt? Controleer eerst de lijst met processen in het systeem. Welke is verantwoordelijk voor een I/O-wachttijd? U kunt iotop gebruiken om dat te controleren:
In ons geval is het vrij duidelijk dat MySQL verantwoordelijk is voor het meeste. We moeten beginnen met de eenvoudigste controle - wat draait er nu precies in de MySQL?
We kunnen zien dat er replicatie-activiteit is op onze slaaf. Wat gebeurt er met de meester?
We kunnen duidelijk zien dat er een batchtaak wordt uitgevoerd. Dit soort eindigt onze reis hier omdat we het probleem vrij gemakkelijk hebben kunnen lokaliseren.
Er zijn echter andere gevallen die misschien niet zo gemakkelijk te begrijpen en te volgen zijn. MySQL wordt geleverd met enige instrumentatie, die bedoeld is om te helpen bij het begrijpen van de I/O-activiteit in het systeem. Zoals we al zeiden, kan I/O op tal van plaatsen in het systeem worden gegenereerd. Schrijfbewerkingen zijn de meest duidelijke, maar we kunnen ook tijdelijke tabellen op de schijf hebben - het is goed om te zien of uw zoekopdrachten dergelijke tabellen gebruiken of niet.
Als je performance_schema hebt ingeschakeld, kun je controleren welke bestanden verantwoordelijk zijn voor de I/O-belasting door 'table_io_waits_summary_by_table' op te vragen:
*************************** 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: 43409881500Zoals je hierboven kunt zien, toont het ook tijdelijke tabellen die in gebruik zijn.
Als u wilt controleren of een bepaalde zoekopdracht een tijdelijke tabel gebruikt, kunt u EXPLAIN FOR CONNECTION gebruiken:
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)In het bovenstaande voorbeeld wordt een tijdelijke tabel gebruikt voor bestandssortering.
Een andere manier om schijfactiviteit in te halen is, als u Percona Server voor MySQL gebruikt, om volledige langzame log-breedsprakigheid in te schakelen:
mysql> SET GLOBAL log_slow_verbosity='full';
Query OK, 0 rows affected (0.00 sec)Vervolgens, in het langzame logboek, ziet u mogelijk items als deze:
# 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();Zoals je kunt zien, kun je zien of er een tijdelijke tabel op schijf was of dat de gegevens op schijf waren gesorteerd. U kunt ook het aantal I/O-bewerkingen en de hoeveelheid toegang tot gegevens controleren.
We hopen dat deze blogpost u zal helpen de I/O-activiteit in het systeem te begrijpen en u deze beter te laten beheren.