Como soluciono problemas e resolvo a alta utilização da CPU em uma instância de banco de dados do Amazon RDS para MySQL ou compatíveis com MySQL do Amazon Aurora?

Breve descrição

O aumento na utilização da CPU pode ser causado por vários fatores, como workloads pesados iniciados pelo usuário, várias consultas simultâneas ou transações de longa duração.

Para identificar a origem da utilização da CPU em sua instância de banco de dados, verifique os seguintes recursos:

• Monitoramento aprimorado
• Insights de Performance
• Consultas que detectam a causa da utilização da CPU no workload
• Logs com monitoramento ativado

Depois de identificar a origem, analise e otimize seu workload para reduzir o uso da CPU.

Resolução

Uso do Monitoramento aprimorado

O Monitoramento aprimorado fornece uma visão em nível de sistema operacional (SO) para identificar a causa de uma alta carga de CPU. Por exemplo, é possível analisar a média de carga, a lista de processos do sistema operacional e a distribuição da CPU System (%) ou Nice (%).

Com o Monitoramento aprimorado, é possível verificar os dados de loadAverageMinute em intervalos de 1, 5 e 15 minutos. Uma carga média maior que o número de vCPUs indica que a instância está sob carga pesada. Se a carga média for menor que o número de vCPUs na classe de instância de banco de dados, o controle de utilização da CPU pode não causar a latência da aplicação. Verifique a carga média para evitar falsos positivos ao diagnosticar a causa do uso da CPU.

Por exemplo, você tem uma instância de banco de dados que usa uma classe de instância db.m5.2xlarge e ela atinge o limite de CPU. A classe da instância tem 8 vCPUs associadas a ela. Uma carga média superior a 170 mostra que a máquina está sob carga pesada durante o período de tempo medido:

Média de carga por minuto:

• Quinze: 170,25
• Cinco: 391,31
• Um: 596,74

Utilização da CPU:

• User (%): 0,71
• System (%): 4,9
• Nice (%): 93,92
• Total (%): 99,97

Observação: o Amazon RDS dá ao seu workload uma prioridade maior em relação a outras tarefas que estão sendo executadas na instância de banco de dados. Para priorizar as tarefas relacionadas ao gerenciamento, as tarefas de workload têm um valor diferente de Nice. Como resultado, no Monitoramento aprimorado, Nice (%) representa a quantidade de CPU que seu workload usa no banco de dados.

Depois de ativar o Monitoramento aprimorado, verifique a lista de processos do sistema operacional associada à instância de banco de dados. O Monitoramento aprimorado mostra no máximo 100 processos. Essa lista pode ajudá-lo a identificar os processos que mais afetam o desempenho da CPU e da memória.

Na seção Lista de processos do sistema operacional de Monitoramento aprimorado, analise os processos do sistema operacional e os processos do RDS. Essas métricas podem ajudar você a verificar se os processos do sistema operacional ou do RDS aumentam o uso da CPU. Ou use essas métricas para monitorar a porcentagem de CPU que os processos mysqld ou aurora usam. Se o Aurora Storage Daemon apresentar alto uso da CPU em uma instância do Aurora, a instância terá um workload de leitura/gravação pesada. Esse alto uso da CPU também pode sugerir que o tamanho da instância pode ser muito pequeno para o volume de armazenamento e o workload atuais. Ou há operações complexas ocorrendo em segundo plano.

Para ver a divisão do uso da CPU, consulte a métrica cpuUtilization. Para obter mais informações, consulte Monitorar métricas do SO com o Monitoramento aprimorado.

Observação: se você ativar o Performance Schema, será possível mapear o ID da thread do sistema operacional para o ID do processo somente para sua instância de banco de dados MySQL do RDS. Não é possível mapear o ID da thread do sistema operacional para o ID do processo da sua instância de banco de dados do Aurora MySQL. Para obter mais informações, consulte Por que minha instância de banco de dados do Amazon RDS usa memória swap quando tenho memória suficiente?

Use o Database Insights

Importante: o Insights de Performance chegará ao fim de sua vida útil em 30 de junho de 2026. É possível fazer o upgrade para o modo Avançado do Database Insights antes de 30 de junho de 2026. Se você não fizer o upgrade, os clusters de banco de dados que usam o Insights de Performance usarão como padrão o modo Padrão do Database Insights. Somente o modo Avançado do Database Insights será compatível com planos de execução e análises sob demanda. Se seus clusters usarem como padrão o modo Padrão, talvez você não consiga usar esses recursos no console. Para ativar o modo Avançado, consulte Ativação do modo Avançado do Database Insights para Amazon RDS. Além disso, consulte Ativação do modo Avançado do Database Insights para Amazon Aurora.

É possível usar o Database Insights para identificar as consultas que são executadas na instância de banco de dados e causam alto uso da CPU.

Primeiro, ative o Database Insights em sua instância do MySQL. Em seguida, use o Database Insights para otimizar seu workload. Também é possível trabalhar com seu administrador do banco de dados para identificar a causa raiz do problema.

Para obter mais informações sobre suporte a mecanismos, regiões da AWS e classes de instâncias, consulte O mecanismo de banco de dados do Amazon Aurora, a região e a classe de instância são compatíveis com o Database Insights. Além disso, consulte O mecanismo de banco de dados do Amazon RDS, a região e a classe de instância são compatíveis com o Database Insights.

Use consultas para detectar a causa do uso da CPU no workload

Antes de ser possível otimizar seu workload, você deve identificar a consulta problemática. Execute as seguintes consultas quando o problema de alta utilização da CPU ocorrer para identificar a causa raiz da utilização da CPU.

Para visualizar os threads em execução na sua instância do MySQL, execute o comando SHOW FULL PROCESSLIST:

SHOW FULL PROCESSLIST;

Observação: execute a consulta SHOW PROCESSLIST como usuário principal do sistema. Você deve ter permissões MySQL PROCESS de administração do servidor para ver todos os threads executados em uma instância do MySQL. Sem permissões de administrador, SHOW PROCESSLIST mostrará somente os threads associados à conta do MySQL que você estiver usando.

Às vezes, o mesmo conjunto de instruções pode continuar sendo executado sem ser concluído. Quando isso acontece, as instruções subsequentes devem aguardar o término do primeiro conjunto de instruções. Isso ocorre porque o bloqueio em nível de linha do InnoDB pode atualizar as mesmas linhas. Para obter mais informações, consulte SHOW PROCESSLIST statement (Declaração SHOW PROCESSLIST) no site do MySQL.

A tabela INNODB_TRX fornece informações sobre todas as transações do InnoDB que são executadas e não são transações somente para leitura. Para visualizar a tabela INNODB_TRX, execute a seguinte consulta:

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

A tabela INNODB_LOCKS fornece informações sobre bloqueios que uma transação do InnoDB solicita, mas não recebe. Para visualizar a tabela INNODB_LOCKS, execute a seguinte consulta:

Para MySQL 5.7 ou anterior:

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

Para MySQL 8.0:

SELECT * FROM performance_schema.data_locks;

Para obter mais informações, consulte a seção The INFORMATION_SCHEMA.INNODB_LOCKS table (A tabela INFORMATION_SCHEMA.INNODB_LOCKS) do MySQL 5.7 e a seção The data_locks table (A tabela data_locks) do MySQL 8.0 no site do MySQL.

A tabela INNODB_LOCK_WAITS fornece uma ou mais linhas para cada transação bloqueada do InnoDB. Para visualizar a tabela INNODB_LOCKS_WAITS, execute a consulta a seguir.

Para MySQL 5.7 ou anterior:

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

Para MySQL 8.0:

SELECT * FROM performance_schema.data_lock_waits;

Execute uma consulta semelhante à seguinte para ver as transações em espera e as transações que estão bloqueando as transações em espera:

Para MySQL 5.7 ou anterior:

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,  
  r.trx_query waiting_query,  
  b.trx_id blocking_trx_id,  
  b.trx_mysql_thread_id blocking_thread,  
  b.trx_query blocking_query  
FROM       information_schema.innodb_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_trx_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_trx_id;

Para MySQL 8.0:

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,  
  r.trx_query waiting_query,  
  b.trx_id blocking_trx_id,  
  b.trx_mysql_thread_id blocking_thread,  
  b.trx_query blocking_query  
FROM       performance_schema.data_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_engine_transaction_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_engine_transaction_id;

Para interpretar a saída dessa consulta, consulte a seção Using InnoDB transaction and locking information (Usando informações de transação e bloqueio do InnoDB) do MySQL 8.0 no site do MySQL.

Para obter informações do monitor padrão do InnoDB sobre o estado do mecanismo de armazenamento do InnoDB, execute a seguinte consulta:

SHOW ENGINE INNODB STATUS;

Para obter mais informações, consulte a seção SHOW ENGINE Statement (Declaração SHOW ENGINE) do MySQL 8.0 no site do MySQL.

Para ver o status do servidor, execute o comando a seguir.

SHOW GLOBAL STATUS;

Para obter mais informações, consulte a seção SHOW STATUS statement (Declaração SHOW STATUS) do MySQL 8.0 no site do MySQL.

Para verificar o tamanho da lista do histórico (history list length, HLL), execute o seguinte comando:

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

Se seu workload exigir várias transações abertas ou de longa duração, seu banco de dados pode ter um HLL grande. Além disso, se as threads de limpeza não conseguirem acompanhar as mudanças no banco de dados, é possível ter um HLL grande. Um HLL grande causa maior uso de recursos e desempenho lento e inconsistente da declaração SELECT.

Em uma instância de gravação do Aurora MySQL, use a métrica RollbackSegmentHistoryListLength do CloudWatch para monitorar seu HLL.

Se a instância tiver um HLL grande, consulte sua declaração SQL. Esse problema ocorre quando você aplica START TRANSACTION e não há COMMIT. Como a thread entrou em um estado INATIVO, não é possível ver a declaração SQL anterior.

Para solucionar esse problema, execute o seguinte comando:

SELECT event_id, current_schema, sql_text, lock_time
 FROM performance_schema.events_statements_history
 WHERE thread_id=<thread_id>  
 ORDER BY event_id DESC;

Analise logs e ative o monitoramento

Analise o log de consulta geral do MySQL para ver o que o mysqld está fazendo em um momento específico. Também é possível visualizar as consultas que são executadas na sua instância em um horário específico, como informações sobre quando os clientes se conectam ou se desconectam. Para obter mais informações, consulte The General Query Log (O log de consulta geral) no site do MySQL.

Importante: quando você ativa o log de consulta geral por longos períodos, os logs consomem armazenamento e podem aumentar a sobrecarga de desempenho.

Analise os logs de consulta lenta do MySQL para encontrar consultas que demoram mais para serem executadas do que os segundos que você definiu para long_query_time. Também é possível examinar seu workload e analisar suas consultas para melhorar o desempenho e o consumo de memória. Para obter mais informações, consulte 7.4.5 The slow query log (7.4.5 Log de consulta lenta) no site do MySQL.

Observação: quando você usa o log de consulta lenta ou o log de consulta geral, é uma prática recomendada definir o parâmetro log_output como FILE.

Use o MariaDB Audit Plugin para auditar a atividade do banco de dados no Amazon RDS para MySQL ou no Amazon RDS para MariaDB. Por exemplo, rastreie usuários que fazem login no banco de dados ou consultas executadas no banco de dados.

Se você usa o Aurora compatível com MySQL, é possível usar a Auditoria avançada. A Auditoria avançada fornece mais controle sobre os tipos de consultas que você deseja registrar em log e reduz a sobrecarga do registro em log.

Use o parâmetro innodb_print_all_deadlocks para verificar se há deadlocks e bloqueios de recursos. É possível usar esse parâmetro para registrar informações sobre deadlocks nas transações de usuários do InnoDB no log de erros do MySQL. Para obter mais informações, consulte innodb_print_all_deadlocks no site do MySQL.

Analise e otimize a alto workload da CPU

Depois de identificar a consulta que eleva o uso da CPU, otimize seu workload para reduzir o consumo da CPU.

Se você vir uma consulta que não é necessária para seu workload, pode encerrar a conexão usando o seguinte comando:

CALL mysql.rds_kill(processID);

Importante: quando você encerra as gravações da linguagem de manipulação de dados (Data Manipulation Language, DML) em uma instância, ela reverte a transação interrompida. A reversão das atualizações pode levar muito tempo. Se sua consulta for executada por muito tempo, trabalhe com o administrador do banco de dados para verificar se é possível interromper a consulta.

Para encontrar o processID de uma consulta, execute o comando SHOW FULL PROCESSLIST.

Se você não quiser finalizar a consulta, otimize-a usando EXPLAIN. EXPLAIN mostra as etapas individuais envolvidas quando você executa uma consulta. Para obter mais informações, consulte Optimizing Queries with EXPLAIN (Otimizando consultas com EXPLAIN) no site do MySQL.

Para visualizar os detalhes do perfil, ative a criação de perfil. O comando SHOW PROFILE mostra o uso de recursos para instruções que estão sendo executadas durante a sessão atual. Para obter mais informações, consulte SHOW PROFILE statement (Declaração SHOW PROFILE) no site do MySQL.

Para visualizar e otimizar as estatísticas da tabela, use a consulta ANALYZE TABLE. Para obter mais informações, consulte ANALYZE TABLE statement (Declaração ANALYZE TABLE) no site do MySQL.

Informações relacionadas

Ajustar o Aurora MySQL com eventos de espera

Como ativar e monitorar logs para uma instância de banco de dados do Amazon RDS para MySQL?

Amazon CloudWatch Database Insights applied in real scenarios (Amazon CloudWatch Database Insights aplicado em casos reais)