I / Oパフォーマンスは、MySQLデータベースにとって非常に重要です。データは、さまざまな場所でディスクに対して読み書きされます。ログ、テーブルスペース、バイナリおよびリレーログをやり直します。ソリッドステートドライブの使用が増えると、I / Oパフォーマンスが大幅に向上し、ユーザーはデータベースをさらに高速にプッシュできるようになりますが、それでもI/Oがボトルネックになりデータベース全体のパフォーマンスを制限する要因になる可能性があります。このブログ投稿では、MySQLインスタンスでI/Oパフォーマンスが高いことに気付いた場合に確認したいことを確認します。
I/Oアクティビティの増加に気付いたとしましょう。上のスクリーンショットのように。 I / Oアクティビティが高いことに気付いた場合は、何を確認しますか？まず、システム内のプロセスのリストを確認します。 I / O待機の責任者はどれですか？ iotopを使用して、次のことを確認できます。
この場合、責任があるのはMySQLであることは明らかです。それの大部分。最も単純なチェックから始める必要があります-現在MySQLで正確に何が実行されていますか？
スレーブでレプリケーションアクティビティが発生していることがわかります。マスターに何が起こっているのですか？
バッチロードジョブが実行されていることがはっきりとわかります。問題を非常に簡単に特定できたので、この種の旅はここで終わります。
ただし、他のケースもありますが、理解と追跡がそれほど簡単ではない場合があります。 MySQLには、システム内のI/Oアクティビティの理解を支援することを目的としたいくつかのインストルメンテーションが付属しています。前述したように、I/Oはシステム内のさまざまな場所で生成できます。書き込みは最も明確なものですが、ディスク上に一時テーブルがある場合もあります。クエリでそのようなテーブルが使用されているかどうかを確認することをお勧めします。
performance_schemaを有効にしている場合、I / O負荷の原因となっているファイルを確認する1つの方法は、「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: 43409881500上記のように、使用中の一時テーブルも表示されます。
特定のクエリが一時テーブルを使用しているかどうかを再確認するには、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)上記の例では、ファイルソートに一時テーブルが使用されています。
ディスクアクティビティに追いつく別の方法は、MySQL用のPercona Serverを使用している場合、完全に遅いログの詳細度を有効にすることです。
mysql> SET GLOBAL log_slow_verbosity='full';
Query OK, 0 rows affected (0.00 sec)その後、遅いログに次のようなエントリが表示される場合があります：
# 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();ご覧のとおり、ディスク上に一時テーブルがあったのか、データがディスク上で並べ替えられたのかがわかります。 I/O操作の数とアクセスされたデータの量を確認することもできます。
このブログ投稿が、システムのI / Oアクティビティを理解し、より適切に管理できるようになることを願っています。