Solucionar problemas em workloads para bancos de dados do Aurora MySQL - Amazon Aurora
Métricas de host da instânciaMétricas de banco de dados

Solucionar problemas em workloads para bancos de dados do Aurora MySQL

A workload do banco de dados pode ser vista como leituras e gravações. Com uma compreensão da workload de banco de dados “normal”, é possível ajustar as consultas e o servidor do banco de dados para atender à demanda à medida que ela muda. Há vários motivos pelos quais o desempenho pode mudar, então a primeira etapa é entender o que mudou.

  • Houve um upgrade da versão principal ou secundária?

    Um upgrade da versão principal inclui alterações no código do mecanismo, principalmente no otimizador, que podem alterar o plano de execução da consulta. Ao fazer upgrade das versões do banco de dados, especialmente das principais, é muito importante que você analise a workload do banco de dados e ajuste adequadamente. O ajuste pode envolver a otimização e a reescrita de consultas ou a adição e atualização de configurações de parâmetros, dependendo dos resultados dos testes. Entender o que está causando o impacto permitirá que você comece a se concentrar nessa área específica.

    Consulte mais informações em What is new in MySQL 8.0 e Server and status variables and options added, deprecated, or removed in MySQL 8.0 na documentação do MySQL, e Comparar o Aurora MySQL versão 2 e o Aurora MySQL versão 3.

  • Houve um aumento no processamento de dados (contagem de linhas)?

  • Há mais consultas sendo executadas simultaneamente?

  • Há alterações no esquema ou no banco de dados?

  • Houve defeitos ou correções no código?

Sumário

Métricas de host da instância

Monitore as métricas do host da instância, como CPU, memória e atividade de rede, para ajudar a entender se houve uma alteração na workload. Há dois conceitos principais para entender as mudanças na workload:

  • Utilização: o uso de um dispositivo, como CPU ou disco. Pode ser com base no tempo ou na capacidade.

    • Com base no tempo: a quantidade de tempo em que um recurso está ocupado durante determinado período de observação.

    • Com base na capacidade: a quantidade de throughput que um sistema ou componente pode fornecer, como uma porcentagem de sua capacidade.

  • Saturação: o grau em que mais trabalho é exigido de um recurso do que ele pode processar. Quando o uso com base na capacidade atinge 100%, o trabalho extra não pode ser processado e deve ser colocado na fila.

Uso da CPU

É possível usar as seguintes ferramentas para identificar o uso e a saturação da CPU:

  • O CloudWatch fornece a métrica CPUUtilization. Se isso atingir 100%, a instância estará saturada. No entanto, as métricas do CloudWatch são calculadas em média em mais de um minuto e carecem de granularidade.

    Para obter mais informações sobre métricas do CloudWatch, consulte Métricas no nível da instância do Amazon Aurora.

  • O monitoramento aprimorado fornece métricas retornadas pelo comando top do sistema operacional. Ele mostra as médias de carga e os seguintes estados de CPU, com granularidade de um segundo:

    • Idle (%) = tempo ocioso

    • IRQ (%) = interrupções de software

    • Nice (%) = bom momento para processos com uma boa prioridade.

    • Steal (%) = tempo gasto atendendo outros locatários (relacionado à virtualização)

    • System (%) = hora do sistema

    • User (%) = hora do usuário

    • Wait (%) = espera de E/S

    Para ter mais informações sobre as métricas do Monitoramento Avançado, consulte Métricas do SO para Aurora.

Uso de memória

Se o sistema estiver sob pressão de memória e o consumo de recursos estiver atingindo a saturação, você deverá observar um alto grau de erros de digitalização, paginação, troca e falta de memória.

É possível usar as seguintes ferramentas para identificar o uso e a saturação da memória:

O CloudWatch fornece a métrica FreeableMemory que mostra quanta memória pode ser recuperada limpando alguns dos caches do sistema operacional e a memória livre atual.

Para obter mais informações sobre métricas do CloudWatch, consulte Métricas no nível da instância do Amazon Aurora.

O monitoramento avançado fornece as seguintes métricas que podem ajudar a identificar problemas de uso de memória:

  • Buffers (KB): a quantidade de memória usada para o buffer de solicitações de E/S antes de gravar no dispositivo de armazenamento, em kilobytes.

  • Cached (KB): a quantidade de memória utilizada para o armazenamento em cache da E/S baseada no sistema de arquivos.

  • Free (KB): a quantidade de memória não atribuída, em kilobytes.

  • Swap: em cache, livre e total.

Por exemplo, se você perceber que a instância de banco de dados usa memória Swap, a quantidade total de memória para sua workload será maior do que a instância tem disponível atualmente. Recomendamos aumentar o tamanho da instância de banco de dados ou ajustar a workload para usar menos memória.

Para ter mais informações sobre as métricas do Monitoramento Avançado, consulte Métricas do SO para Aurora.

Para ter informações mais detalhadas sobre como usar o Esquema de Performance e o esquema sys para determinar quais conexões e componentes estão usando memória, consulte Solução de problemas de uso de memória para bancos de dados Aurora MySQL.

Throughput na rede

O CloudWatch fornece as seguintes métricas para throughput total da rede, todas com média de um minuto:

  • NetworkReceiveThroughput: a quantidade de throughput de rede recebida dos clientes por cada instância no cluster de bancos de dados do Aurora.

  • NetworkTransmitThroughput: a quantidade de throughput de rede enviada aos clientes por cada instância no cluster de bancos de dados do Aurora.

  • NetworkThroughput: a quantidade de throughput de rede recebida e transmitida aos clientes por cada instância no cluster de bancos de dados do Aurora.

  • StorageNetworkReceiveThroughput: a quantidade de throughput de rede recebida do subsistema de armazenamento do Aurora por cada instância no cluster de banco de dados.

  • StorageNetworkTransmitThroughput: a quantidade de throughput de rede enviada ao subsistema de armazenamento do Aurora por cada instância no cluster de banco de dados do Aurora.

  • StorageNetworkThroughput: a quantidade de throughput de rede recebida e enviada ao subsistema de armazenamento do Aurora por cada instância no cluster de banco de dados do Aurora.

Para obter mais informações sobre métricas do CloudWatch, consulte Métricas no nível da instância do Amazon Aurora.

O monitoramento avançado fornece os grafos network recebidos (RX) e transmitidos (TX), com granularidade de até um segundo.

Para ter mais informações sobre as métricas do Monitoramento Avançado, consulte Métricas do SO para Aurora.

Métricas de banco de dados

Examine as seguintes métricas do CloudWatch para alterações na workload:

  • BlockedTransactions: o número médio de transações no banco de dados que são bloqueadas por segundo.

  • BufferCacheHitRatio: a porcentagem de solicitações atendidas pelo cache de buffer.

  • CommitThroughput: o número médio de operações de confirmação por segundo.

  • DatabaseConnections: o número de conexões de rede cliente com a instância de banco de dados.

  • Deadlocks: o número médio de deadlocks no banco de dados por segundo.

  • DMLThroughput: o número médio de inserções, atualizações e exclusões por segundo.

  • ResultSetCacheHitRatio: a porcentagem de solicitações atendidas pelo cache de consulta.

  • RollbackSegmentHistoryListLength: os logs de ações desfeitas que registram transações confirmadas com registros marcados para exclusão.

  • RowLockTime: o tempo total gasto adquirindo bloqueios de linha para tabelas do InnoDB.

  • SelectThroughput: o número médio de consultas de seleção por segundo.

Para obter mais informações sobre métricas do CloudWatch, consulte Métricas no nível da instância do Amazon Aurora.

Considere as seguintes perguntas ao examinar a workload:

  1. Houve mudanças recentes na classe da instância de banco de dados, por exemplo, redução do tamanho da instância de 8xlarge para 4xlarge ou alteração de db.r5 para db.r6?

  2. É possível criar um clone e reproduzir o problema ou isso acontece apenas nessa instância?

  3. Há esgotamento dos recursos do servidor, alto esgotamento da CPU ou da memória? Se sim, isso pode significar a necessidade de hardware adicional.

  4. Uma ou mais consultas estão demorando mais?

  5. As alterações são causadas por um upgrade, especialmente de uma versão principal? Se sim, compare as métricas de antes e depois do upgrade.

  6. Há mudanças no número de instâncias de banco de dados do leitor?

  7. Você habilitou os logs gerais, de auditoria ou binários? Para ter mais informações, consulte Registro em log de bancos de dados do Aurora MySQL.

  8. Você habilitou, desabilitou ou alterou o uso da replicação de logs binários (binlogs)?

  9. Há alguma transação de longa duração com um grande número de bloqueios de linha? Examine o tamanho da lista de histórico do InnoDB (HLL) para obter indicações de transações de longa duração.

    Consulte mais informações em O tamanho da lista de histórico do InnoDB aumentou significativamente e na publicação do blog Why is my SELECT query running slowly on my Amazon Aurora MySQL DB cluster?.

    1. Se um grande HLL for causado por uma transação de gravação, isso significa que os logs UNDO estão se acumulando (não estão sendo limpos regularmente). Em uma grande transação de gravação, esse acúmulo pode crescer rapidamente. No MySQL, UNDO é armazenado no espaço de tabela SYSTEM. O espaço de tabela SYSTEM não pode ser reduzido. O log UNDO pode fazer com que o espaço de tabela SYSTEM cresça para vários GB, ou até mesmo TB. Após a limpeza, libere o espaço alocado fazendo backup lógico (despejo) dos dados e, depois, importe o despejo para uma nova instância de banco de dados.

    2. Se um HLL grande for causado por uma transação de leitura (consulta de longa duração), isso poderá indicar que a consulta está usando uma grande quantidade de espaço temporário. Libere o espaço temporário ao reinicializar. Examine as métricas de banco de dados do Performance Insights para verificar quaisquer alterações na seção Temp, como created_tmp_tables. Para ter mais informações, consulte Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora.

  10. É possível dividir transações de longa duração em transações menores que modificam menos linhas?

  11. Há alguma alteração nas transações bloqueadas ou aumento nos deadlocks? Examine as métricas de banco de dados do Performance Insights para verificar quaisquer alterações nas variáveis de status na seção Locks, como innodb_row_lock_time, innodb_row_lock_waits e innodb_dead_locks. Use intervalos de um minuto ou de cinco minutos.

  12. Há um aumento nos eventos de espera? Examine os eventos de espera e os tipos de espera do Performance Insights usando intervalos de um minuto ou de cinco minutos. Analise os principais eventos de espera e veja se eles estão correlacionados às mudanças na workload ou à contenção do banco de dados. Por exemplo, buf_pool mutex indica a contenção do grupo de buffer. Para ter mais informações, consulte Ajustar o Aurora MySQL com eventos de espera.