Co zkontrolovat, zda je využití I/O MySQL vysoké

Výkon I/O je pro databáze MySQL zásadní. Data se čtou a zapisují na disk na mnoha místech. Znovu proveďte protokoly, tabulkové prostory, binární a přenosové protokoly. S rostoucím využíváním jednotek SSD se výrazně zvýšil výkon I/O, což uživatelům umožňuje ještě rychleji prosazovat své databáze, ale i tak se I/O mohou stát úzkým hrdlem a omezujícím faktorem výkonu celé databáze. V tomto příspěvku na blogu se podíváme na věci, které chcete zkontrolovat, pokud si všimnete vysokého I/O výkonu ve vaší instanci MySQL.

Co znamená „Vysoké“ využití I/O? Stručně řečeno, pokud je tím ovlivněn výkon vaší databáze, je vysoký. Obvykle byste si toho všimli, když se zápisy v databázi zpomalily. To se také jasně projeví jako vysoké I/O čekání na vašem systému. Mějte však na paměti, že na hostitelích s 32 a více jádry CPU, i když jedno jádro ukáže 100% čekání na I/O, nemusíte si toho všimnout na agregovaném pohledu – bude to představovat pouze 1/32 celého zatížení. . Zdá se, že to nemá vliv, ale ve skutečnosti některá jednovláknová I/O operace zahlcuje váš CPU a některá aplikace čeká na dokončení této I/O aktivity.

Řekněme, že jsme zaznamenali nárůst I/O aktivity, jen jako na snímku obrazovky výše. Na co se podívat, když si všimnete vysoké I/O aktivity? Nejprve zkontrolujte seznam procesů v systému. Který z nich je zodpovědný za čekání na I/O? Pomocí iotop můžete zkontrolovat, že:

V našem případě je zcela jasné, že je to MySQL, kdo je zodpovědný za většina z toho. Měli bychom začít tou nejjednodušší kontrolou – co přesně v MySQL právě běží?

Můžeme vidět replikační aktivitu na našem slave zařízení. Co se děje s mistrem?

Zřetelně vidíme, že probíhá nějaká úloha dávkového načítání. Tímto způsobem naše cesta končí, protože se nám podařilo poměrně snadno určit problém.

Existují však další případy, které nemusí být tak snadné pochopit a sledovat. MySQL přichází s určitou instrumentací, která má pomoci s pochopením I/O aktivity v systému. Jak jsme zmínili, I/O lze generovat na mnoha místech v systému. Zápisy jsou nejpřehlednější, ale můžeme mít také dočasné tabulky na disku – je dobré zjistit, zda vaše dotazy takové tabulky používají nebo ne.

Pokud máte povoleno schéma performance_schema, jedním ze způsobů, jak zkontrolovat, které soubory jsou zodpovědné za zatížení I/O, může být dotaz ‘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

Jak můžete vidět výše, zobrazuje také dočasné tabulky, které se používají.

Chcete-li znovu zkontrolovat, zda konkrétní dotaz používá dočasnou tabulku, můžete použít 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)

Ve výše uvedeném příkladu je pro řazení souborů použita dočasná tabulka.

Dalším způsobem, jak dohnat aktivitu disku, je, pokud náhodou používáte Percona Server pro MySQL, povolit plnou pomalou podrobnost protokolu:

mysql> SET GLOBAL log_slow_verbosity='full';

Query OK, 0 rows affected (0.00 sec)

Potom v pomalém protokolu můžete vidět záznamy jako:

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

Jak vidíte, můžete zjistit, zda byla na disku dočasná tabulka nebo zda byla data na disku setříděna. Můžete také zkontrolovat počet I/O operací a množství zpřístupněných dat.

Doufáme, že vám tento příspěvek na blogu pomůže porozumět I/O aktivitě v systému a umožní vám ji lépe spravovat.