MariaDB
 sql >> Database >  >> RDS >> MariaDB

Cosa controllare se l'utilizzo di MySQL I/O è elevato

Le prestazioni di I/O sono vitali per i database MySQL. I dati vengono letti e scritti sul disco in numerose posizioni. Registri di ripristino, tablespace, registri binari e di inoltro. Con l'aumento dell'utilizzo delle unità a stato solido, le prestazioni di I/O sono aumentate in modo significativo, consentendo agli utenti di eseguire il push dei loro database ancora più velocemente, ma anche in questo caso l'I/O può diventare un collo di bottiglia e un fattore limitante delle prestazioni dell'intero database. In questo post del blog daremo un'occhiata alle cose che vuoi controllare se noti che le tue prestazioni di I/O sono elevate sulla tua istanza MySQL.

Cosa significa utilizzo I/O "alto"? In breve, se le prestazioni del tuo database ne sono influenzate, è elevato. In genere lo noterai mentre le scritture rallentano nel database. Si manifesterà anche chiaramente come un'attesa I/O elevata sul tuo sistema. Tieni presente, tuttavia, che su host con 32 e più core CPU, anche se un core mostrerà il 100% di attesa I/O, potresti non notarlo in una vista aggregata:rappresenterà solo 1/32 dell'intero carico . Sembra non avere alcun impatto, ma in realtà alcune operazioni di I/O a thread singolo stanno saturando la CPU e alcune applicazioni stanno aspettando che l'attività di I/O finisca.

Diciamo di aver notato un aumento dell'attività di I/O, solo come nello screenshot qui sopra. Cosa guardare se hai notato un'elevata attività di I/O? Innanzitutto, controlla l'elenco dei processi nel sistema. Quale è responsabile di un'attesa di I/O? Puoi usare iotop per verificare che:

Nel nostro caso è abbastanza chiaro che MySQL è responsabile di la maggior parte. Dovremmo iniziare con il controllo più semplice:cosa è esattamente in esecuzione in MySQL in questo momento?

Possiamo vedere che c'è attività di replica sul nostro slave. Cosa sta succedendo al maestro?

Possiamo vedere chiaramente che alcuni lavori di caricamento batch sono in esecuzione. Questo tipo di termina il nostro viaggio qui poiché siamo riusciti a individuare il problema abbastanza facilmente.

Ci sono altri casi, tuttavia, che potrebbero non essere così facili da capire e monitorare. MySQL viene fornito con alcuni strumenti, che hanno lo scopo di aiutare a comprendere l'attività di I/O nel sistema. Come accennato, l'I/O può essere generato in numerosi punti del sistema. Le scritture sono le più chiare, ma potremmo anche avere tabelle temporanee su disco:è utile vedere se le tue query utilizzano tali tabelle o meno.

Se hai performance_schema abilitato, un modo per controllare quali file sono responsabili del carico di I/O può essere quello di interrogare "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

Come puoi vedere sopra, mostra anche le tabelle temporanee in uso.

Per verificare se una particolare query utilizza una tabella temporanea, puoi utilizzare 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)

Nell'esempio sopra una tabella temporanea è usata per filesort.

Un altro modo per recuperare l'attività del disco è, se ti capita di utilizzare Percona Server per MySQL, abilitare la verbosità completa del registro lento:

mysql> SET GLOBAL log_slow_verbosity='full';

Query OK, 0 rows affected (0.00 sec)

Quindi, nel registro lento, potresti vedere voci come questa:

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

Come puoi vedere, puoi dire se c'era una tabella temporanea su disco o se i dati sono stati ordinati su disco. Puoi anche controllare il numero di operazioni di I/O e la quantità di dati a cui si accede.

Ci auguriamo che questo post del blog ti aiuti a comprendere l'attività di I/O nel sistema e a gestirla meglio.