Apa yang Harus Diperiksa jika Pemanfaatan I/O MySQL Tinggi?

Kinerja I/O sangat penting untuk database MySQL. Data dibaca dan ditulis ke disk di banyak tempat. Ulangi log, tablespace, log biner dan relai. Dengan peningkatan penggunaan solid state drive, kinerja I/O telah meningkat secara signifikan sehingga memungkinkan pengguna untuk mendorong basis data mereka lebih cepat, tetapi meskipun demikian I/O dapat menjadi penghambat dan faktor pembatas kinerja seluruh basis data. Dalam posting blog ini kita akan melihat hal-hal yang ingin Anda periksa jika Anda melihat kinerja I/O Anda tinggi pada instance MySQL Anda.

Apa yang dimaksud dengan pemanfaatan I/O “Tinggi”? Singkatnya, jika kinerja database Anda dipengaruhi olehnya, itu tinggi. Biasanya Anda akan melihatnya sebagai penulisan yang melambat di database. Ini juga akan dengan jelas bermanifestasi sebagai I/O tinggi menunggu di sistem Anda. Harap diingat, meskipun, pada host dengan 32 dan lebih banyak inti CPU, bahkan jika satu inti akan menunjukkan 100% I/O menunggu, Anda mungkin tidak melihatnya pada tampilan agregat - itu hanya akan mewakili 1/32 dari seluruh beban . Tampaknya tidak berdampak, tetapi sebenarnya beberapa operasi I/O satu utas menjenuhkan CPU Anda dan beberapa aplikasi menunggu aktivitas I/O tersebut selesai.

Katakanlah kita memang melihat peningkatan aktivitas I/O, hanya seperti pada tangkapan layar di atas. Apa yang harus dilihat jika Anda melihat aktivitas I/O yang tinggi? Pertama, periksa daftar proses dalam sistem. Mana yang bertanggung jawab untuk menunggu I/O? Anda dapat menggunakan iotop untuk memeriksa bahwa:

Dalam kasus kami, cukup jelas bahwa MySQL yang bertanggung jawab untuk kebanyakan dari itu. Kita harus mulai dengan pemeriksaan yang paling sederhana - apa sebenarnya yang sedang berjalan di MySQL saat ini?

Kita bisa melihat ada aktivitas replikasi pada slave kita. Apa yang terjadi pada tuannya?

Kita dapat dengan jelas melihat beberapa pekerjaan pemuatan batch sedang berjalan. Hal ini mengakhiri perjalanan kami di sini karena kami berhasil menemukan masalahnya dengan cukup mudah.

Namun, ada kasus lain, yang mungkin tidak mudah dipahami dan dilacak. MySQL dilengkapi dengan beberapa instrumentasi, yang dimaksudkan untuk membantu memahami aktivitas I/O dalam sistem. Seperti yang kami sebutkan, I/O dapat dihasilkan di banyak tempat dalam sistem. Penulisan adalah yang paling jelas tetapi kami mungkin juga memiliki tabel sementara di disk - ada baiknya untuk melihat apakah kueri Anda menggunakan tabel tersebut atau tidak.

Jika Anda mengaktifkan performance_schema, salah satu cara untuk memeriksa file mana yang bertanggung jawab atas pemuatan I/O adalah dengan menanyakan '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

Seperti yang Anda lihat di atas, ini juga menunjukkan tabel sementara yang sedang digunakan.

Untuk memeriksa ulang apakah kueri tertentu menggunakan tabel sementara, Anda dapat menggunakan 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)

Pada contoh di atas tabel sementara digunakan untuk filesort.

Cara lain untuk mengejar aktivitas disk adalah, jika Anda menggunakan Server Percona untuk MySQL, untuk mengaktifkan log verbositas lambat penuh:

mysql> SET GLOBAL log_slow_verbosity='full';

Query OK, 0 rows affected (0.00 sec)

Kemudian, di log lambat, Anda mungkin melihat entri seperti ini:

# 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();

Seperti yang Anda lihat, Anda dapat mengetahui apakah ada tabel sementara pada disk atau apakah data diurutkan pada disk. Anda juga dapat memeriksa jumlah operasi I/O dan jumlah data yang diakses.

Kami berharap entri blog ini akan membantu Anda memahami aktivitas I/O dalam sistem dan memungkinkan Anda mengelolanya dengan lebih baik.