MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Какво да проверите дали използването на MySQL I/O е високо

Производството на I/O е жизненоважно за MySQL бази данни. Данните се четат и записват на диска на много места. Повторете регистрационни файлове, пространства за таблици, двоични и релейни регистрационни файлове. С увеличаването на използването на SSD устройствата I/O производителността се е увеличила значително, което позволява на потребителите да избутват своите бази данни още по-бързо, но дори и тогава I/O може да се превърне в тесно място и ограничаващ фактор за производителността на цялата база данни. В тази публикация в блога ще разгледаме нещата, които искате да проверите, ако забележите, че вашата I/O производителност е висока във вашия MySQL екземпляр.

Какво означава „високо“ използване на I/O? Накратко, ако производителността на вашата база данни е засегната от това, тя е висока. Обикновено ще забележите, че записите се забавят в базата данни. Също така ясно ще се прояви като високо I/O чакане на вашата система. Моля, имайте предвид обаче, че на хостове с 32 и повече процесорни ядра, дори ако едно ядро ​​ще покаже 100% I/O чакане, може да не го забележите в обобщен изглед - то ще представлява само 1/32 от цялото натоварване . Изглежда, че не оказва влияние, но всъщност някаква еднонишкова I/O операция насища вашия процесор и някое приложение чака тази I/O активност да приключи.

Да приемем, че забелязахме увеличение на I/O активността, просто както на екранната снимка по-горе. Какво да погледнете, ако сте забелязали висока I/O активност? Първо проверете списъка с процесите в системата. Кой е отговорен за I/O чакане? Можете да използвате iotop, за да проверите това:

В нашия случай е съвсем ясно, че MySQL отговаря за повечето. Трябва да започнем с най-простата проверка - какво точно се изпълнява в MySQL в момента?

Можем да видим, че има репликационна активност на нашия подчинен. Какво се случва с господаря?

Можем ясно да видим, че се изпълнява някаква задача за пакетно зареждане. Това приключва нашето пътуване до тук, тъй като успяхме да определим проблема доста лесно.

Има и други случаи, които може да не са толкова лесни за разбиране и проследяване. MySQL идва с някои инструменти, които са предназначени да помогнат при разбирането на I/O активността в системата. Както споменахме, I/O може да се генерира на много места в системата. Най-ясни са записите, но може да имаме и временни таблици на диска – добре е да видите дали вашите заявки използват такива таблици или не.

Ако сте активирали performance_schema, един от начините да проверите кои файлове са отговорни за I/O натоварването може да бъде да запитате „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)

В горния пример се използва временна таблица за сортиране на файлове.

Друг начин за наваксване на дисковата активност е, ако случайно използвате Percona Server за MySQL, да активирате пълната бавна многословност на журнала:

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 активността в системата и да ви позволи да я управлявате по-добре.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. 20 съвета:Подгответе вашата база данни за Черен петък и Кибер понеделник

  2. Как работи DEGREES() в MariaDB

  3. Изпълняване на заявки за анализ на големи данни с помощта на SQL и Presto

  4. Върнете само числови стойности в MariaDB

  5. MariaDB CURRENT_TIMESTAMP() Обяснено