MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

O que verificar se a utilização de E/S do MySQL é alta

O desempenho de E/S é vital para bancos de dados MySQL. Os dados são lidos e gravados no disco em vários lugares. Redo logs, tablespaces, logs binários e de retransmissão. Com o aumento do uso de unidades de estado sólido, o desempenho de E/S aumentou significativamente, permitindo que os usuários enviem seus bancos de dados ainda mais rápido, mas mesmo assim a E/S pode se tornar um gargalo e um fator limitante do desempenho de todo o banco de dados. Nesta postagem do blog, veremos o que você deseja verificar se perceber que o desempenho de E/S está alto em sua instância do MySQL.

O que significa "Alta" utilização de E/S? Em suma, se o desempenho do seu banco de dados for afetado por ele, ele será alto. Normalmente, você notaria como as gravações ficam mais lentas no banco de dados. Também se manifestará claramente como alta espera de E/S em seu sistema. Lembre-se, porém, em hosts com 32 ou mais núcleos de CPU, mesmo que um núcleo mostre 100% de espera de E/S, você pode não notá-lo em uma exibição agregada - ele representará apenas 1/32 de toda a carga . Parece não impactar, mas na verdade alguma operação de E/S de thread único está saturando sua CPU e alguns aplicativos estão aguardando a conclusão dessa atividade de E/S.

Digamos que notamos um aumento na atividade de E/S, apenas como na imagem acima. O que observar se você notar uma alta atividade de E/S? Primeiro, verifique a lista de processos no sistema. Qual deles é responsável por uma espera de E/S? Você pode usar o iotop para verificar se:

No nosso caso é bastante claro que é o MySQL que é responsável por a maior parte. Devemos começar com a verificação mais simples - o que exatamente está sendo executado no MySQL agora?

Podemos ver que há atividade de replicação em nosso slave. O que está acontecendo com o mestre?

Podemos ver claramente que algum trabalho de carregamento em lote está em execução. Isso meio que encerra nossa jornada aqui, pois conseguimos identificar o problema com bastante facilidade.

Há outros casos, porém, que podem não ser tão fáceis de entender e rastrear. O MySQL vem com alguma instrumentação, destinada a ajudar no entendimento da atividade de E/S no sistema. Como mencionamos, a E/S pode ser gerada em vários locais do sistema. As gravações são as mais claras, mas também podemos ter tabelas temporárias no disco - é bom ver se suas consultas usam essas tabelas ou não.

Se você tiver performance_schema habilitado, uma maneira de verificar quais arquivos são responsáveis ​​pela carga de E/S pode ser consultar ‘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

Como você pode ver acima, também mostra as tabelas temporárias que estão em uso.

Para verificar novamente se uma consulta específica usa uma tabela temporária, você pode usar 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)

No exemplo acima, uma tabela temporária é usada para classificação de arquivos.

Outra maneira de recuperar a atividade do disco é, se você usar o Percona Server para MySQL, habilitar o detalhamento completo do log lento:

mysql> SET GLOBAL log_slow_verbosity='full';

Query OK, 0 rows affected (0.00 sec)

Então, no log lento, você pode ver entradas como esta:

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

Como você pode ver, você pode dizer se havia uma tabela temporária no disco ou se os dados foram ordenados no disco. Você também pode verificar o número de operações de E/S e a quantidade de dados acessados.

Esperamos que esta postagem do blog ajude você a entender a atividade de E/S no sistema e permita que você a gerencie melhor.