Die I/O-Leistung ist für MySQL-Datenbanken entscheidend. An zahlreichen Stellen werden Daten gelesen und auf die Platte geschrieben. Redo-Logs, Tablespaces, Binär- und Relay-Logs. Mit zunehmender Nutzung von Solid-State-Laufwerken hat sich die E/A-Leistung deutlich erhöht, sodass Benutzer ihre Datenbanken noch schneller pushen können, aber selbst dann kann E/A zu einem Engpass und einem einschränkenden Faktor für die Leistung der gesamten Datenbank werden. In diesem Blogbeitrag werfen wir einen Blick auf die Dinge, die Sie überprüfen sollten, wenn Sie feststellen, dass Ihre E/A-Leistung auf Ihrer MySQL-Instanz hoch ist.
Was bedeutet „hohe“ E/A-Auslastung? Kurz gesagt, wenn die Leistung Ihrer Datenbank davon betroffen ist, ist sie hoch. Normalerweise würden Sie es bemerken, wenn Schreibvorgänge in der Datenbank langsamer werden. Es wird sich auch deutlich als hohe E/A-Wartezeit auf Ihrem System manifestieren. Bitte denken Sie jedoch daran, dass Sie auf Hosts mit 32 und mehr CPU-Kernen, selbst wenn ein Kern 100 % E/A-Wartezeit anzeigt, dies möglicherweise nicht in einer aggregierten Ansicht bemerken – es wird nur 1/32 der gesamten Last darstellen . Scheint keine Auswirkungen zu haben, aber tatsächlich überlastet eine Singlethread-E/A-Operation Ihre CPU und einige Anwendungen warten darauf, dass diese E/A-Aktivität beendet wird.
Nehmen wir an, wir haben einfach einen Anstieg der E/A-Aktivität bemerkt wie im Screenshot oben. Worauf sollten Sie achten, wenn Sie eine hohe I/O-Aktivität bemerkt haben? Überprüfen Sie zunächst die Liste der Prozesse im System. Welcher ist für eine I/O-Wartezeit verantwortlich? Sie können dies mit iotop überprüfen:
In unserem Fall ist ganz klar, dass MySQL dafür verantwortlich ist das meiste. Wir sollten mit der einfachsten Prüfung beginnen - was genau läuft gerade in MySQL?
Wir können sehen, dass auf unserem Slave Replikationsaktivität vorhanden ist. Was passiert mit dem Meister?
Wir können deutlich sehen, dass ein Stapelladejob ausgeführt wird. Damit endet unsere Reise hierher, da wir es geschafft haben, das Problem ganz einfach zu lokalisieren.
Es gibt jedoch auch andere Fälle, die möglicherweise nicht so einfach zu verstehen und zu verfolgen sind. MySQL wird mit einigen Instrumenten geliefert, die dabei helfen sollen, die E/A-Aktivität im System zu verstehen. Wie bereits erwähnt, können I/O an zahlreichen Stellen im System generiert werden. Schreibvorgänge sind die klarsten, aber wir haben möglicherweise auch temporäre Tabellen auf der Festplatte - es ist gut zu sehen, ob Ihre Abfragen solche Tabellen verwenden oder nicht.
Wenn Sie performance_schema aktiviert haben, kann eine Möglichkeit zum Überprüfen, welche Dateien für die E/A-Last verantwortlich sind, darin bestehen, ‘table_io_waits_summary_by_table’ abzufragen:
*************************** 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: 43409881500Wie Sie oben sehen können, zeigt es auch temporäre Tabellen, die verwendet werden.
Um zu überprüfen, ob eine bestimmte Abfrage eine temporäre Tabelle verwendet, können Sie EXPLAIN FOR CONNECTION:
verwendenmysql> 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)Im obigen Beispiel wird eine temporäre Tabelle für die Dateisortierung verwendet.
Eine andere Möglichkeit, die Festplattenaktivität aufzuholen, besteht darin, wenn Sie zufällig Percona Server für MySQL verwenden, die vollständige langsame Protokollausführlichkeit zu aktivieren:
mysql> SET GLOBAL log_slow_verbosity='full';
Query OK, 0 rows affected (0.00 sec)Dann sehen Sie im langsamen Protokoll möglicherweise Einträge wie diese:
# 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();Wie Sie sehen können, können Sie feststellen, ob sich auf der Festplatte eine temporäre Tabelle befand oder ob die Daten auf der Festplatte sortiert wurden. Sie können auch die Anzahl der E/A-Vorgänge und die Menge der abgerufenen Daten überprüfen.
Wir hoffen, dass dieser Blogbeitrag Ihnen hilft, die E/A-Aktivität im System zu verstehen und besser zu verwalten.
