Vad du ska kontrollera om MySQL I/O-användningen är hög

I/O-prestandan är avgörande för MySQL-databaser. Data läses och skrivs till disken på många ställen. Gör om loggar, tabellutrymmen, binära och reläloggar. Med en ökning av användningen av solid state-enheter har I/O-prestandan ökat avsevärt, vilket gör det möjligt för användare att driva sina databaser ännu snabbare, men även då kan I/O bli en flaskhals och en begränsande faktor för prestanda för hela databasen. I det här blogginlägget kommer vi att ta en titt på de saker du vill kontrollera om du märker att din I/O-prestanda är hög på din MySQL-instans.

Vad betyder "Hög" I/O-användning? Kort sagt, om prestandan för din databas påverkas av den är den hög. Vanligtvis skulle du märka det som att skrivningar saktar ner i databasen. Det kommer också tydligt att visa sig som hög I/O väntan på ditt system. Kom dock ihåg att på värdar med 32 eller fler CPU-kärnor, även om en kärna visar 100 % I/O-väntetid, kanske du inte märker det i en aggregerad vy - den kommer bara att representera 1/32 av hela belastningen . Verkar inte påverka men i själva verket mättar vissa enkeltrådade I/O-operationer din CPU och någon applikation väntar på att den I/O-aktiviteten ska avslutas.

Låt oss säga att vi märkte en ökning av I/O-aktiviteten, bara som i skärmdumpen ovan. Vad ska du titta på om du märkte hög I/O-aktivitet? Kontrollera först listan över processerna i systemet. Vem är ansvarig för en I/O-väntetid? Du kan använda iotop för att kontrollera att:

I vårt fall är det helt klart att det är MySQL som ansvarar för det mesta. Vi bör börja med den enklaste kontrollen - vad exakt körs i MySQL just nu?

Vi kan se att det finns replikeringsaktivitet på vår slav. Vad händer med mästaren?

Vi kan tydligt se att något batchladdningsjobb körs. Det här avslutar vår resa här eftersom vi lyckades hitta problemet ganska enkelt.

Det finns dock andra fall som kanske inte är så lätta att förstå och spåra. MySQL kommer med viss instrumentering, som är avsedd att hjälpa till att förstå I/O-aktiviteten i systemet. Som vi nämnde kan I/O genereras på många ställen i systemet. Skrivningar är de mest tydliga, men vi kan också ha tillfälliga tabeller på disken - det är bra att se om dina frågor använder sådana tabeller eller inte.

Om du har aktiverat performance_schema kan ett sätt att kontrollera vilka filer som är ansvariga för I/O-belastningen vara att fråga '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

Som du kan se ovan visar den även tillfälliga tabeller som används.

För att dubbelkolla om en viss fråga använder en temporär tabell kan du använda 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)

I exemplet ovan används en temporär tabell för filsortering.

Ett annat sätt att fånga upp diskaktivitet är, om du råkar använda Percona Server för MySQL, att aktivera fullständig långsam logginformation:

mysql> SET GLOBAL log_slow_verbosity='full';

Query OK, 0 rows affected (0.00 sec)

Sedan, i den långsamma loggen, kan du se poster så här:

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

Som du kan se kan du se om det fanns en tillfällig tabell på disken eller om data sorterades på disken. Du kan också kontrollera antalet I/O-operationer och mängden åtkomst till data.

Vi hoppas att det här blogginlägget hjälper dig att förstå I/O-aktiviteten i systemet och låter dig hantera den bättre.