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.
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.
NotaTeste 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.
-
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:
Faça login no console do DAS.
No painel de navegação à esquerda, clique em .
Localize a instância de destino e clique em no ID da instância para abrir a página de detalhes da instância.
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.
-
-
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:
Faça login em um banco de dados usando o console do DMS.
Na parte superior da página, clique em SQL Window e selecione o banco de dados desejado.
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.
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
Faça login no console do ApsaraDB RDS. Na lista de Instances, clique em na instância de destino.
No painel de navegação à esquerda, escolha Autonomy Service > One-Click Diagnosis.
Clique em na aba Session Management.
Clique em no botão SQL Throttling.
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 significaRecursos 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
Versões aplicáveis
ApsaraDB RDS for MySQL
ApsaraDB RDS for MariaDB