Todos os produtos
Search
Central de documentação

ApsaraDB RDS:Alta utilização de CPU em instâncias do ApsaraDB RDS for MySQL/MariaDB

Última atualização: Jun 26, 2026

Problema

A utilização de CPU de uma instância do ApsaraDB RDS for MySQL/MariaDB está elevada, chegando a atingir 100%.

Causas

Este tópico descreve duas causas comuns para a utilização de CPU em 100% e suas respectivas soluções: alta carga da aplicação (alto QPS) e alto custo de consulta devido a consultas SQL lentas. Quando uma aplicação envia operações de consulta ou modificação de dados, o sistema executa um grande número de leituras lógicas. A E/S lógica refere-se à quantidade de linhas de dados que o sistema precisa acessar nas tabelas para executar uma consulta. Consequentemente, o sistema consome recursos significativos de CPU para manter a consistência dos dados transferidos do armazenamento para a memória. No MySQL, a alta utilização de CPU geralmente resulta de consultas SQL lentas e custosas que acessam muitas linhas da tabela.

Nota

Este tópico não aborda casos em que a alta utilização de CPU é causada por um grande número de conflitos de bloqueio de linha, esperas de bloqueio ou tarefas em segundo plano, pois esses cenários são raros.

  • Alta carga da aplicação (alto QPS):

    • Características: A instância apresenta alto QPS com consultas simples e eficientes, oferecendo pouca margem para otimização.

    • Sintomas: Não há consultas SQL lentas observadas, ou elas não são a causa principal. As tendências de QPS e utilização de CPU são consistentes.

    • Cenários comuns: Esse problema é frequente em sistemas de processamento de transações online (OLTP) otimizados, como sistemas de pedidos, aplicações web populares com altas taxas de leitura e testes de estresse de terceiros, como os realizados com Sysbench.

  • Alto custo de consulta devido a consultas SQL lentas (acesso a muitas linhas):

    • Características: O QPS da instância não é alto, mas a execução da consulta é ineficiente e exige varreduras de grandes volumes de dados da tabela. Existe um potencial significativo de otimização.

    • Sintomas: Consultas SQL lentas estão presentes. As tendências de QPS e utilização de CPU não correspondem.

    • Análise da causa: A baixa eficiência da consulta força o sistema a acessar grandes quantidades de dados para retornar resultados, resultando em uma E/S lógica média elevada. Portanto, mesmo quando o QPS não é alto (por exemplo, em um site com pouco tráfego), a utilização de CPU da instância ainda pode ser alta.

Soluções

Escolha uma solução com base na sua situação específica.

Alta carga da aplicação (alto QPS)

Quando a alta utilização de CPU é causada por uma carga elevada da aplicação, geralmente há pouca margem para otimização de SQL. Resolva esse problema ajustando a arquitetura da aplicação ou a configuração da instância:

  • Atualize o tipo de instância para aumentar os recursos de CPU. Para mais informações, consulte Alterar configuração.

  • Adicione uma instância somente leitura e direcione consultas que não sejam sensíveis à consistência de dados, como buscas de categorias de produtos ou horários de trens, para essa instância. Isso reduz a carga na instância primária. Para mais informações, consulte Crie uma instância somente leitura do MySQL.

  • Utilize o PolarDB-X, um banco de dados distribuído nativo da nuvem, para fragmentar dados automaticamente e distribuir a carga de consultas entre várias instâncias RDS.

  • Use o ApsaraDB for Memcache ou Tair para servir resultados de consultas frequentes a partir do cache, reduzindo assim a carga na instância RDS.

  • Para aplicações com dados relativamente estáticos, alta repetição de consultas e conjuntos de resultados menores que 1 MB, considere habilitar o cache de consultas.

    Nota

    Teste se a ativação do cache de consultas beneficia sua aplicação. Para mais informações sobre as configurações, consulte Defina e usar o cache de consultas para ApsaraDB RDS for MySQL.

  • Arquive dados históricos periodicamente. Utilize sharding ou particionamento para reduzir a quantidade de dados acessados pelas consultas. Otimize suas consultas para diminuir os custos de execução e melhorar a escalabilidade da aplicação.

Alto custo de consulta devido a consultas SQL lentas

Para resolver esse problema, identifique consultas ineficientes, melhore sua eficiência de execução e reduza seus custos.

  1. Identifique consultas ineficientes usando um dos seguintes métodos:

    • Execute as seguintes instruções SQL para visualizar as consultas em execução no momento.

      show processlist;
      show full processlist;

      O sistema retorna uma saída semelhante à seguinte:

      mysql> show processlist;
      +----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
      | Id       | User  | Host              | db      | Command | Time  | State        | Info                                         |
      +----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
      |101031643 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |117731567 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |134298793 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |134384670 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   |     0 | Init         | show processlist                             |
      |234891284 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |235125098 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |235200576 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |235633985 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |235887773 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |251990394 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      |252662718 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
      +----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
      11 rows in set (0.00 sec)

      Sessões de consulta em execução há muito tempo e em estados como Sending data, Copying to tmp table, Copying to tmp table on disk, Sorting result ou Using filesort podem apresentar problemas de desempenho.

      • Em cenários onde o alto QPS causa alta utilização de CPU, as consultas geralmente são executadas rapidamente. Pode ser difícil capturar consultas em execução no momento usando o comando show processlist; ou visualizando as sessões da instância. No entanto, execute a seguinte instrução SQL para analisar uma consulta.

        explain [$SQL]
        Nota

        [$SQL] representa a consulta SQL com problemas de desempenho.

      • Execute um comando como kill [$ID]; para encerrar sessões de longa duração. Para mais informações, consulte Encerrar uma sessão em uma instância do ApsaraDB RDS for MySQL.

        Nota

        [$ID] representa o ID da sessão correspondente à consulta.

    • Use o Database Autonomy Service (DAS) para visualizar as consultas em execução no momento:

      1. Faça login no console do DAS.

      2. No painel de navegação à esquerda, clique em Intelligent O&M Center > Instance Monitoring.

      3. Localize a instância de destino e clique em no ID da instância para abrir a página de detalhes da instância.

      4. Clique em no texto da consulta na coluna SQL para exibir a consulta completa e seu plano de execução.

    • Monitore continuamente o desempenho de execução de SQL usando o SQL Insight and Auditing. No painel de navegação à esquerda da página de detalhes da instância, escolha Autonomy Service > SQL Insight and Auditing. Visualize informações detalhadas, como tempo de execução do SQL e número de linhas verificadas, para localizar instruções SQL que consomem muita CPU.

  2. Após identificar consultas que precisam de otimização, use o SQL Diagnostics no console do Data Management Service (DMS) para obter sugestões de otimização. Para solucionar problemas históricos, os relatórios de diagnóstico também são indispensáveis:

    1. Faça login em um banco de dados usando o console do DMS.

    2. Na parte superior da página, clique em SQL Window e selecione o banco de dados desejado.

    3. Cole a instrução de consulta na janela SQL e clique em SQL Diagnostics para obter sugestões de otimização. O resultado do diagnóstico inclui a instrução SQL, o plano de execução (que mostra o tipo de consulta, as tabelas envolvidas e o número de linhas verificadas) e sugestões de diagnóstico de índice que fornecem instruções DDL prontas para execução.

  3. Aplique as otimizações recomendadas. Por exemplo, após adicionar um índice sugerido, verifique se o custo de execução da consulta diminuiu significativamente.

Medidas de mitigação de curto prazo

Se a utilização de CPU permanecer alta e não for possível otimizar consultas SQL lentas rapidamente, utilize as medidas a seguir para aliviar a pressão sobre a CPU.

Controle a concorrência de consultas SQL lentas usando limitação de SQL

  1. Faça login no console do ApsaraDB RDS. Na lista de Instances, clique em na instância de destino.

  2. No painel de navegação à esquerda, escolha Autonomy Service > One-Click Diagnosis.

  3. Clique em na aba Session Management.

  4. Clique em no botão SQL Throttling.

  5. Clique em Create Throttling Rule e configure o modo de limitação, regra, banco de dados, concorrência máxima e duração da limitação.

Atualize temporariamente o tipo de instância

Se o encerramento de sessões e a limitação de SQL não aliviarem a pressão sobre a CPU, atualize temporariamente o tipo de instância para aumentar os recursos de CPU. Na página Basic Information da instância, na seção Configuration Information, clique em Change configuration para atualizar a instância. Para mais informações, consulte Alterar configuração.

Mais informações

Recursos para solucionar problemas de desempenho

O Data Management Service (DMS) oferece vários recursos para ajudar a solucionar e resolver problemas de desempenho da instância. O relatório de diagnóstico é a ferramenta mais eficaz para solucionar problemas de desempenho em instâncias do ApsaraDB RDS for MySQL e ApsaraDB RDS for MariaDB. Independentemente da causa do problema de desempenho, comece sempre revisando o relatório de diagnóstico, especialmente as seções de otimização de SQL, lista de sessões e resumo de consultas SQL lentas.

Prevenção de utilização de CPU em 100%

As diretrizes a seguir ajudam a evitar que a utilização de CPU atinja 100%:

  • Configure alertas de utilização de CPU para garantir que haja margem suficiente de CPU na sua instância.

  • Durante o projeto e desenvolvimento da aplicação, considere a otimização de consultas. Siga os princípios gerais de otimização do MySQL para reduzir a E/S lógica das consultas e melhorar a escalabilidade da aplicação.

  • Antes de lançar novos recursos ou módulos, realize testes de estresse com dados de produção .

  • Antes de lançar novos recursos ou módulos, execute testes de regressão com dados de produção.

Algoritmo de recursos do sistema

O modelo simplificado a seguir ilustra a relação entre os recursos do sistema, o custo de execução de instruções SQL e as consultas por segundo (QPS):

  • Condição: O modelo da aplicação é constante, o que significa que o código da aplicação não foi modificado.

  • avg_lgc_io: A E/S lógica média necessária para executar cada consulta.

  • total_lgc_io: A quantidade total de E/S lógica que os recursos de CPU da instância conseguem processar por unidade de tempo.

  • Fórmula: total_lgc_io = avg_lgc_io × QPS, que significa Recursos totais de CPU por unidade de tempo = E/S lógica média por consulta × Número de consultas por unidade de tempo.

Documentos relacionados

Usar o Database Autonomy Service para resolver alta utilização de CPU em instâncias do ApsaraDB RDS for MySQL

Versões aplicáveis

  • ApsaraDB RDS for MySQL

  • ApsaraDB RDS for MariaDB