Co sprawdzić, czy wykorzystanie We/Wy MySQL jest wysokie?

Wydajność we/wy ma kluczowe znaczenie dla baz danych MySQL. Dane są odczytywane i zapisywane na dysku w wielu miejscach. Przerób logi, przestrzenie tabel, logi binarne i przekaźnikowe. Wraz ze wzrostem wykorzystania dysków półprzewodnikowych wydajność I/O znacznie wzrosła, pozwalając użytkownikom na jeszcze szybsze przesyłanie ich baz danych, ale nawet wtedy I/O może stać się wąskim gardłem i czynnikiem ograniczającym wydajność całej bazy danych. W tym poście na blogu przyjrzymy się rzeczom, które chcesz sprawdzić, jeśli zauważysz, że wydajność I/O jest wysoka na Twojej instancji MySQL.

Co oznacza „Wysokie” wykorzystanie I/O? Krótko mówiąc, jeśli ma to wpływ na wydajność Twojej bazy danych, jest ona wysoka. Zazwyczaj można to zauważyć jako spowolnienie zapisu w bazie danych. Będzie to również wyraźnie widoczne, gdy w systemie czeka wysokie I/O. Należy jednak pamiętać, że na hostach z 32 i więcej rdzeniami CPU, nawet jeśli jeden rdzeń pokaże 100% oczekiwania na I/O, możesz tego nie zauważyć w widoku zagregowanym - będzie reprezentował tylko 1/32 całego obciążenia . Wydaje się, że nie ma to wpływu, ale w rzeczywistości jakaś jednowątkowa operacja I/O nasyca procesor i jakaś aplikacja czeka na zakończenie tej operacji I/O.

Powiedzmy, że zauważyliśmy wzrost aktywności we/wy, po prostu jak na powyższym zrzucie ekranu. Na co zwrócić uwagę, jeśli zauważyłeś dużą aktywność we/wy? Najpierw sprawdź listę procesów w systemie. Który z nich odpowiada za oczekiwanie na I/O? Możesz użyć iotop, aby sprawdzić, czy:

W naszym przypadku jest całkiem jasne, że to MySQL odpowiada za większość z tego. Powinniśmy zacząć od najprostszego sprawdzenia - co dokładnie jest teraz uruchomione w MySQL?

Widać, że na naszym urządzeniu podrzędnym trwa replikacja. Co się dzieje z mistrzem?

Wyraźnie widać, że pewne zadanie ładowania wsadowego jest uruchomione. Ten rodzaj kończy naszą podróż tutaj, ponieważ udało nam się dość łatwo zidentyfikować problem.

Istnieją jednak inne przypadki, które mogą nie być tak łatwe do zrozumienia i śledzenia. MySQL jest dostarczany z pewnym instrumentarium, które ma pomóc w zrozumieniu aktywności I/O w systemie. Jak wspomnieliśmy, I/O można generować w wielu miejscach w systemie. Zapisy są najbardziej przejrzyste, ale możemy również mieć tymczasowe tabele na dysku – dobrze jest sprawdzić, czy Twoje zapytania używają takich tabel, czy nie.

Jeśli masz włączony schemat performance_schema, jednym ze sposobów sprawdzenia, które pliki są odpowiedzialne za ładowanie we/wy, może być zapytanie „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 widać powyżej, pokazuje również używane tabele tymczasowe.

Aby dokładnie sprawdzić, czy dane zapytanie używa tabeli tymczasowej, możesz użyć opcji WYJAŚNIJ POŁĄCZENIE:

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)

W powyższym przykładzie tabela tymczasowa jest używana do sortowania plików.

Innym sposobem na nadrobienie zaległości na dysku jest, jeśli zdarzy ci się używać Percona Server dla MySQL, włączenie pełnej, wolnej szczegółowości logów:

mysql> SET GLOBAL log_slow_verbosity='full';

Query OK, 0 rows affected (0.00 sec)

Następnie w wolnym dzienniku możesz zobaczyć wpisy takie jak:

# 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 widać, można stwierdzić, czy na dysku znajdowała się tymczasowa tabela lub czy dane zostały posortowane na dysku. Możesz także sprawdzić liczbę operacji we/wy i ilość dostępnych danych.

Mamy nadzieję, że ten wpis na blogu pomoże Ci zrozumieć aktywność we/wy w systemie i pozwoli Ci lepiej nią zarządzać.