Monitoramento eficaz do MySQL com painéis SCUMM:Parte 3

Métricas do MySQL InnoDB

• 
  Idade do ponto de verificação do Innodb
  
  De acordo com o manual, o checkpointing é definido da seguinte forma:“À medida que as alterações são feitas nas páginas de dados que são armazenadas em cache no buffer pool , essas alterações são gravadas nos arquivos de dados algum tempo depois, um processo conhecido como flushing . O ponto de verificação é um registro das últimas alterações (representado por um LSN value) que foram gravados com sucesso nos arquivos de dados ”. Este gráfico é útil quando você deseja determinar como seu servidor está realizando o checkpoint de dados em seu disco. Isso pode ser uma boa referência se seu log de transações (redo log ou ib_logfile0) for muito grande. Este gráfico também é um bom indicador se você precisar ajustar variáveis ​​como innodb_log_file_size, innodb_log_buffer_size, innodb_max_dirty_pages_pct ou innodb_adaptive_flushing_method. Quanto mais próxima a idade do ponto de verificação estiver da idade máxima do ponto de verificação, mais preenchidos serão os logs e o InnoDB fará mais E/S para manter algum espaço livre nos logs. O mecanismo de checkpointing difere em detalhes sutis entre os sabores baseados no Percona XtraDB, MariaDB e a versão do Oracle, você também pode encontrar diferenças em sua implementação entre as versões do MySQL.
  
• 
  Transações InnoDB
  
  Sempre que houver uma grande transação em andamento em seu servidor MySQL, este gráfico é uma boa referência. Ele contará as transações que foram criadas em um momento específico, e o comprimento do histórico (ou é, na verdade, o comprimento da lista de histórico encontrado em SHOW ENGINE INNODB STATUS) é o número de páginas no log de desfazer. As tendências que você verá aqui são um bom recurso para verificar se isso pode significar, por exemplo, que a limpeza está atrasada devido a uma taxa de inserção muito alta de recarregar os dados ou devido a uma transação de longa duração, ou se a limpeza simplesmente pode não acompanha devido a uma alta E/S de disco no volume em que seu $DATADIR reside.
  
• 
  Operações de linha do Innodb
  
  Para determinadas tarefas de DBA, você pode querer determinar o número de exclusões, inserções, leituras e linhas atualizadas. Então este gráfico é o que você pode usar para verificar isso.
  
• 
  Tempo de bloqueio de linha do Innodb
  
  Este gráfico é um bom recurso para observar quando você perceber que seu aplicativo está encontrando muitas ocorrências para “Tempo limite de espera de bloqueio excedido; tente reiniciar a transação ”. Isso também pode ajudá-lo a determinar se você pode ter uma indicação para usar consultas incorretas ao lidar com bloqueios. Essa também é uma boa referência a ser observada ao otimizar suas consultas que envolvem o bloqueio de linhas. Se o tempo de espera for muito alto, você precisa verificar o log de consultas lentas ou executar um pt-query-digest e ver quais são as consultas suspeitas que causam esse inchaço no gráfico.
  
• 
  E/S do InnoDB
  
  Sempre que você quiser determinar a quantidade de leituras de dados do InnoDB, liberações de disco, gravações e gravações de log, este gráfico tem o que você precisa observar. Você pode usar este gráfico para determinar se suas variáveis ​​InnoDB estão bem ajustadas para lidar com seus requisitos específicos. Por exemplo, se você tiver o cache do Módulo de Backup de Bateria, mas não estiver obtendo muito de seu desempenho ideal, poderá confiar neste gráfico para determinar se seus fsyncs() são maiores do que o esperado. Em seguida, alterar a variável innodb_flush_method e usar O_DSYNC pode resolver o problema.
  
• 
  Uso do arquivo de log do InnoDB por hora
  
  Este gráfico mostra apenas o número de bytes gravados nos arquivos de redo log do InnoDB e o crescimento de seus arquivos de log do InnoDB com base no intervalo de tempo de 24 horas da data atual.
  
• 
  Desempenho de registro do InnoDB
  
  Este gráfico está intimamente relacionado ao gráfico por hora de uso do arquivo de log do InnoDB. Você precisa usar este gráfico sempre que precisar determinar o tamanho do innodb_log_file_size. Você pode determinar o número de bytes gravados nos arquivos de redo log do InnoDB e com que eficiência seu MySQL libera os dados da memória para o disco. Sempre que você estiver com pouco tempo para usar seu espaço de redo log, isso indicaria que você precisa aumentar o tamanho do arquivo innodb_log_file. Nesse caso, este gráfico diria que você precisa fazer isso. No entanto, para aprofundar o quanto você precisa para o seu innodb_log_file, pode fazer mais sentido verificar o LSN (Log Sequence Number) em SHOW ENGINE INNODB STATUS. Percona tem um bom blog relacionado a isso, que é uma boa fonte para se olhar.
  
• 
  Impasses do InnoDB
  
  Em certas situações em que seu cliente de aplicação está frequentemente enfrentando deadlocks ou você tem que ver quanto seu MySQL está enfrentando deadlocks, este gráfico serve ao propósito. Os deadlocks indicam que você tem um design SQL ruim, o que leva suas transações a criar uma condição de corrida causando deadlocks.
  
• 
  Empilhamento de condição do índice
  
  Uma pequena palavra de cautela ao olhar para este gráfico. Primeiro, você tem que determinar que você tem sua variável global do MySQL innodb_monitor_enable configurada para o valor correto que é module_icp. Caso contrário, você experimentará um "Sem pontos de dados", conforme mostrado abaixo:
  
  A finalidade do gráfico, se tiver pontos de dados definidos como o que tenho nas saídas de amostra, fornecerá a um DBA uma visão de quão bem suas consultas estão se beneficiando com o Index Condition Pushdown ou ICP. O ICP é um ótimo recurso do MySQL que oferece otimização para suas consultas. Em vez de o MySQL ler as linhas completas filtradas em suas consultas WHERE na recuperação, ele adicionará mais verificações após seus índices secundários. Isso adiciona mais granularidade e economiza tempo, caso contrário, o mecanismo precisa ler as linhas da tabela completa quando se baseia apenas no índice filtrado e nenhum ICP é usado. Isso evita ler as linhas completas correspondentes às tuplas de índice que correspondem aos índices secundários.
  
  Deixe-me elaborar um pouco sobre este gráfico, digamos que eu tenha uma tabela chamada:
  

  mysql> show create table a\G
  *************************** 1. row ***************************
         Table: a
  Create Table: CREATE TABLE `a` (
    `id` int(11) NOT NULL,
    `age` int(11) NOT NULL,
    KEY `id` (`id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  1 row in set (0.00 sec)

  
  E tem alguns pequenos dados:
  

  mysql> select * from a;
  +----+-----+
  | id | age |
  +----+-----+
  |  1 |   1 |
  |  2 |   1 |
  |  3 |   1 |
  |  3 |  41 |
  |  4 |  41 |
  |  5 |   4 |
  |  4 |   4 |
  |  4 |   4 |
  +----+-----+
  8 rows in set (0.00 sec)

  
  Quando o ICP está habilitado, os resultados são mais eficientes e viáveis:
  

  mysql> explain extended select * from a where id>2 and id<4 and age=41;
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  |  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  1 row in set, 2 warnings (0.00 sec)

  
  Do que sem ICP,
  

  mysql> set optimizer_switch='index_condition_pushdown=off';
  Query OK, 0 rows affected (0.00 sec)
  
  mysql> explain extended select * from a where id>2 and id<4 and age=41;
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  |  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  1 row in set, 2 warnings (0.00 sec)

  
  Este é um exemplo simples de ICP e como esse gráfico pode beneficiar um DBA.
  
• 
  Conteúdo do pool de buffers do InnoDB
  
  Ao trabalhar com MySQL e usando o mecanismo InnoDB, este gráfico é um dos valores mais comuns (innodb_buffer_pool*) que você precisa ajustar para otimizar o desempenho do MySQL. Falando especificamente em seu conteúdo de buffer pool, ele exibe as tendências de páginas sujas em relação ao conteúdo total do buffer pool. O conteúdo total do buffer pool inclui as páginas limpas além das páginas sujas. Determinando o quão eficiente seu MySQL está lidando com o buffer pool, este gráfico serve ao seu propósito.
  
• 
  Páginas do conjunto de buffers do InnoDB
  
  Este gráfico é útil quando você deseja verificar a eficiência do MySQL usando seu pool de buffers InnoDB. Você pode usar este gráfico, por exemplo, se seu tráfego diário não preencher o innodb_buffer_pool_size atribuído, isso pode indicar que certas partes de um aplicativo não são úteis ou não servem a nenhum propósito ou se você definir o innodb_buffer_pool_size muito alto o que pode ser bom para diminuir o valor e recuperar espaço em sua memória.
  
• 
  E/S do conjunto de buffers do InnoDB
  
  Quando você precisa verificar o número de páginas criadas e gravadas em tabelas InnoDB ou leituras de páginas no buffer pool InnoDB por operações em tabelas InnoDB.
  
• 
  Solicitações do pool de buffers do InnoDB
  
  Quando você deseja determinar a eficiência com que suas consultas estão acessando o pool de buffers do InnoDB, este gráfico serve ao propósito. Este gráfico mostrará as tendências com base nos pontos de dados sobre o desempenho do seu servidor MySQL quando o mecanismo InnoDB tem que acessar frequentemente o disco (a indicação do buffer pool ainda não foi aquecido), com que frequência as solicitações do buffer pool estavam lidando com solicitações de leitura e gravação solicitações de.
  
• 
  Leitura antecipada do InnoDB
  
  Quando você tiver a variável innodb_random_read_ahead definida como ON, adicione este gráfico como uma tendência valiosa a ser observada como parte de sua rotina de DBA. Ele mostra as tendências de como seu mecanismo de armazenamento MySQL InnoDB gerencia o pool de buffers pelo thread de segundo plano de leitura antecipada, como ele gerencia aqueles posteriormente despejados sem terem sido acessados ​​por consultas e como o InnoDB inicia a leitura antecipada aleatória quando uma consulta verifica uma grande parte de uma mesa, mas em ordem aleatória.
  
• 
  Buffer de alteração do InnoDB
  
  Quando você tem o Percona Server 5.7 em execução, este gráfico é útil ao monitorar quão bem o InnoDB alocou o buffer de alterações. Essas alterações incluem as inserções, atualizações e exclusões especificadas pela variável innodb_change_buffering. O buffer de alterações ajuda a acelerar as consultas, evitando E/S de acesso aleatório substancial que seria necessário para ler as páginas de índice secundárias do disco.
  
• 
  Atividade do buffer de alteração do InnoDB
  
  Isso está relacionado ao gráfico do InnoDB Change Buffer, mas disseca as informações em pontos de dados mais viáveis. Eles fornecem mais informações para monitorar como o InnoDB lida com o buffer de alterações. Isso é útil em uma tarefa de DBA específica para determinar se seu innodb_change_buffer_max_size está definido com um valor muito alto, pois o buffer de alterações compartilha a mesma memória do buffer pool do InnoDB, reduzindo a memória disponível para páginas de dados em cache. Você pode ter que considerar desabilitar o buffer de mudança se o conjunto de trabalho quase se encaixar no buffer pool ou se suas tabelas tiverem relativamente poucos índices secundários. Lembre-se de que o buffer de alterações não impõe sobrecarga extra, porque se aplica apenas a páginas que não estão no conjunto de buffers. Esse gráfico também é útil se você precisar determinar como as mesclagens são úteis se precisar comparar seu aplicativo com base em determinadas solicitações para cenários específicos. Digamos que você tenha inserções em massa, você precisa definir innodb_change_buffering=insert e determinar se os valores definidos em seu pool de buffers e innodb_change_buffer_max_size não afetam a E/S do disco, especialmente durante a recuperação ou desligamento lento (necessário se você deseja fazer um failover com baixo requisito de tempo de inatividade). Além disso, esse gráfico pode servir para avaliar determinados cenários, pois a mesclagem do buffer de alteração pode levar várias horas quando há vários índices secundários para atualizar e muitas linhas afetadas. Durante esse tempo, a E/S de disco é aumentada, o que pode causar uma lentidão significativa nas consultas vinculadas ao disco.
  

Esquema de desempenho do MySQL

• 
  E/S do arquivo de esquema de desempenho (eventos)
  
  Este gráfico busca pontos de dados relacionados a quaisquer eventos ocorridos no MySQL que possam ter sido instrumentados para criar várias instâncias do objeto instrumentado (por exemplo, leituras de log binários ou leituras de arquivos de dados InnoDB). Cada linha resume os eventos de um determinado nome de evento. Por exemplo, se houver um instrumento para um mutex criado para cada conexão, poderá haver muitas instâncias desse evento instrumentado, pois há várias conexões. A linha de resumo do instrumento resume todas essas instâncias. Você pode verificar esses eventos no manual do MySQL para tabelas de resumo do esquema de desempenho para obter mais informações.
  
• 
  E/S do arquivo de esquema de desempenho (carregar)
  
  Este gráfico é igual ao gráfico “E/S do arquivo de esquema de desempenho (Eventos)”, exceto que é instrumentado com base na carga.
  
• 
  E/S do arquivo de esquema de desempenho (bytes)
  
  Este gráfico é igual ao gráfico “Performance Schema File IO (Events)”, exceto que é instrumentado com base no tamanho em bytes. Por exemplo, quanto tempo um evento específico levou quando o MySQL acionou o evento wait/io/file/innodb/innodb_data_file.
  
• 
  Esperas de esquema de desempenho (eventos)
  
  Este gráfico tem o gráfico de dados para todas as esperas gastas em um evento específico. Você pode verificar as Tabelas de resumo de eventos de espera no manual para obter mais informações.
  
• 
  Esperas de esquema de desempenho (carregar)
  
  Igual ao gráfico “Performance Schema Waits (Events)”, mas desta vez mostra as tendências para a carga.
  
• 
  Operações de acesso ao índice (carregar)
  
  Este gráfico é uma agregação de todos os eventos de espera de E/S de índice de tabela agrupados por índice(s) de uma tabela, conforme gerado pelo instrumento wait/io/table/sql/handler. Você pode verificar o manual do MySQL sobre a tabela de Esquema de Desempenho table_io_waits_summary_by_index_usage para obter mais informações.
  
• 
  Operações de acesso à tabela (carregar)
  
  Gráfico “Igual ao Index Access Operations (Load)”, é uma agregação de todos os eventos de espera de E/S de tabela agrupados por tabela, conforme gerado pelo instrumento wait/io/table/sql/handler. Isso é muito útil para DBAs. Por exemplo, você gostaria de rastrear a velocidade necessária para acessar (buscar) ou atualizar (inserir, excluir, atualizar) uma tabela específica. Você pode verificar no manual do MySQL sobre a tabela de Esquema de Desempenho table_io_waits_summary_by_table para obter mais informações.
  
• 
  Esquema de desempenho SQL e bloqueios externos (eventos)
  
  Este gráfico é uma agregação (contagem de quantas vezes ocorreu) de todos os eventos de espera de bloqueio de tabela, conforme gerado pelo instrumento wait/lock/table/sql/handler que é agrupado por tabela. O bloqueio SQL aqui no gráfico significa os bloqueios internos. Esses bloqueios internos são leitura normal, leitura com bloqueios compartilhados, leitura de alta prioridade, leitura sem inserção, permissão de gravação, inserção simultânea de gravação, atraso na gravação, prioridade baixa e gravação normal. Enquanto os bloqueios externos são de leitura externa e gravação externa. Em qualquer tarefa de DBA, isso é muito útil se você precisar rastrear e investigar bloqueios em uma tabela específica, independentemente de seu tipo. Você pode verificar a tabela table_lock_waits_summary_by_table para obter mais informações.
  
• 
  Esquema de desempenho SQL e bloqueios externos (segundos)
  
  Igual ao gráfico “Performance Schema SQL &External Locks (Events)”, mas especificado em segundos. Se você quiser procurar os bloqueios de sua tabela com base nos segundos em que os bloqueios foram mantidos, esse gráfico é seu bom recurso.
  

Conclusão