:High CPU utilization in PolarDB for MySQL

Com a expansão do seu negócio, a especificação atual do cluster pode se tornar insuficiente. Os gráficos de desempenho geralmente mostram métricas como QPS ou IOPS com tendência de alta, seguindo um padrão semelhante ao da utilização de CPU

Se a CPU for o gargalo, provavelmente a especificação do cluster não atende mais ao tráfego do seu negócio. Resolva essa questão adicionando um nó somente leitura ao cluster de banco de dados ou aumentando a especificação do cluster.

• Para cargas de trabalho compostas principalmente por requisições de leitura, adicione um nó somente leitura para escalar horizontalmente o cluster e distribuir o tráfego de leitura. Para mais informações, consulte Add or remove nodes.

• Quando a carga de trabalho consiste majoritariamente em requisições de escrita, adicionar um nó somente leitura não melhora o desempenho. Nesse cenário, manually scale up a especificação do cluster, por exemplo, fazendo upgrade de uma especificação de 4 núcleos para uma de 8 núcleos.

Consultas lentas

Frequentemente, a alta utilização de CPU resulta de instruções SQL ineficientes que geram consultas lentas e acúmulo de threads ativas. No entanto, determine primeiro se as consultas lentas são a causa raiz da alta utilização de CPU ou se outro gargalo de recursos está desacelerando as consultas e aumentando indiretamente o uso da CPU.

Visualize as consultas lentas no PolarDB console navegando até Diagnostics and Optimization > Slow SQL. Na aba Slow Log Details, se o valor de Scanned Rows for significativamente maior que o valor de Returned Rows, isso indica que consultas lentas estão causando a alta utilização de CPU.

Consultas TP envolvem uma quantidade muito pequena de leituras e escritas de dados. Se uma consulta examinar um grande volume de dados, é muito provável que falte um índice. Por exemplo, se uma consulta na lista de consultas lentas mostrar que mais de 10.000 linhas foram examinadas, mas apenas uma linha foi retornada, isso é um indício claro de que falta um índice na coluna name.

SELECT * FROM table1 WHERE name='testname';

Use a seguinte instrução para verificar se existe um índice na coluna name.

SHOW index FROM table1;

• Caso a coluna name não possua índice, adicione um com a seguinte instrução para eliminar consultas lentas causadas por exames de dados em larga escala.

  ALTER TABLE table1 ADD KEY ix_name (name);

• Se a coluna name já tiver um índice, use a instrução abaixo para visualizar o plano de execução da instrução SQL e confirme se o índice correto está sendo utilizado.

  EXPLAIN SELECT * FROM table1 WHERE name='testname';

  Ao constatar que existe um índice na coluna name mas ele não é utilizado, estatísticas imprecisas podem ter gerado um plano de execução incorreto. Execute a seguinte instrução para regenerar as estatísticas da tabela e corrigir o plano.

  ANALYZE TABLE table1;

  Após a conclusão do comando, verifique novamente o plano de execução para confirmar que o índice correto agora está em uso:

  EXPLAIN SELECT * FROM table1 WHERE name='testname';

FAQ: Por que instruções SQL idênticas e volumes de exame resultam em uso de CPU significativamente diferente entre clusters PolarDB distintos?

A saturação de CPU geralmente é causada por requisições lentas. Mesmo que o texto SQL e o volume teórico de exame pareçam idênticos em diferentes clusters, o comportamento real de execução pode variar. Investigue as seguintes áreas:

1. Compare os detalhes reais dos logs de consultas lentas: Revise e compare os logs de consultas lentas de ambos os clusters para confirmar se as linhas examinadas, linhas retornadas e tempo de execução diferem. A mesma instrução SQL pode ter planos de execução diferentes ou encontrar distribuições de dados distintas em clusters diferentes.

2. Verifique diferenças na arquitetura do cluster: Confirme se o cluster com alta carga possui menos nós somente leitura do que o cluster com baixa carga. Se as requisições de leitura não estiverem sendo descarregadas para nós somente leitura, o nó primário suportará uma carga maior, resultando em maior uso de CPU.

3. Recomendações de otimização: Para evitar saturação de CPU, foque em otimizar requisições lentas e reduzir o número real de linhas examinadas pelas instruções SQL, em vez de apenas verificar se o texto SQL é idêntico.

Alta contagem de threads ativas

Uma contagem elevada de threads ativas sempre aumenta a utilização de CPU. No MySQL, cada núcleo de CPU processa apenas uma requisição por vez. Por exemplo, um cluster de 16 núcleos lida com no máximo 16 requisições simultâneas no nível do kernel, o que difere da concorrência no nível da aplicação. Visualize as informações de sessão no PolarDB console navegando até Diagnostics and Optimization > One-click diagnosis > Sessions.

Se você descartar consultas lentas como causa das falhas no processamento de requisições, o acúmulo de threads ativas normalmente decorre de um aumento no tráfego de produção. Consulte view the performance curves para verificar isso. Caso as tendências gerais de tráfego e requisições coincidam com a tendência de acúmulo de threads ativas, os recursos do cluster atingiram seu limite. Para resolver esse problema, adicione nós somente leitura ao cluster de banco de dados ou aumente as especificações do cluster.

Quando o número de threads ativas atinge um ponto crítico, pode ocorrer contenção de CPU, gerando inúmeros mutex locks no kernel. Os gráficos de desempenho geralmente mostram alta utilização de CPU, alta contagem de threads ativas e baixo IOPS ou QPS. Outra causa é um pico repentino de tráfego, em que uma alta taxa de novas conexões também leva à contenção de CPU e acúmulo de requisições. Muitas vezes, mitigue esse problema ativando o recurso thread pool do cluster para controle de fluxo. Se a contagem de threads ativas diminuir, verifique se ainda há tarefas acumuladas no lado da aplicação. Caso a carga de CPU e a contagem de threads ativas permaneçam altas, considere também aumentar a especificação do cluster.

Uma tempestade de conexões de frontend também pode causar um pico instantâneo de tráfego no cluster. Trata-se de tráfego anormal, frequentemente causado por web crawlers. Utilize o throttling de SQL para rejeitar requisições. Para mais informações, consulte Session Management.

Configuração inadequada do kernel

Os parâmetros padrão de uma instância MySQL autogerenciada são configurados para cenários de uso geral, podendo não ser ideais para todas as cargas de trabalho e exigindo ajustes finos. Alguns problemas podem não aparecer nos estágios iniciais da aplicação, quando o volume de dados é pequeno, mas surgem conforme os dados crescem e condições específicas são atendidas.

A contenção de memória é um problema comum. Na arquitetura MySQL, a memória é usada principalmente para cache de dados. As áreas de memória mais utilizadas são o buffer pool e o innodb_adaptive_hash_index. A área de cache de todo o sistema de banco de dados é onde os dados são trocados com maior frequência. Se houver memória insuficiente ou contenção de páginas de memória, pode ocorrer acúmulo de diversas exceções e consultas lentas. Um sintoma típico é um pico repentino no uso de CPU até seu nível máximo, acompanhado de consultas lentas. Se a investigação revelar que o problema não é falta de índice, a falha pode estar no sistema de memória.

Por exemplo, ao executar uma operação truncate table, o MySQL percorre o buffer pool para evictar todas as páginas de dados da tabela que sofreu truncate. Em um cluster de grande porte, se innodb_buffer_pool_instances estiver definido como 1 e a concorrência for relativamente alta, problemas de contenção podem ocorrer. Esse problema pode ser detectado cedo no ciclo de vida do service e geralmente é evitado alinhando o valor de innodb_buffer_pool_instances com o número de núcleos de CPU e particionando o buffer pool em buckets.

Outro cenário é a contenção pelo innodb_adaptive_hash_index. Um sintoma claro é um grande número de esperas hash0hash.cc.

SHOW ENGINE innodb STATUS;

Na seção AHI da saída, você verá uma distorção significativa de dados.

insert 0, delete mark 0, delete 0
Hash table size 25499819, node heap has 20720 buffer(s)
Hash table size 25499819, node heap has 25111 buffer(s)
Hash table size 25499819, node heap has 23884 buffer(s)
Hash table size 25499819, node heap has 16835 buffer(s)
Hash table size 25499819, node heap has 23132 buffer(s)
Hash table size 25499819, node heap has 189284 buffer(s)
Hash table size 25499819, node heap has 38864 buffer(s)
Hash table size 25499819, node heap has 49094 buffer(s)
5469.32 hash searches/s, 5282.36 non-hash searches/s

Para esse tipo de problema, desative o parâmetro innodb_adaptive_hash_index, o que consequentemente desativa o recurso AHI. Dados mostram que, em cenários mistos de leitura e escrita, o AHI pode ter impacto negativo no desempenho, mas desativá-lo não afeta significativamente o negócio como um todo.

Anomalia de recursos de memória causando alta CPU ou failover primário/standby

Anomalias em recursos de memória podem causar indiretamente alto uso de CPU, falhas na instância ou failovers primário/standby (HA). Os cenários a seguir cobrem causas comuns, incluindo memória atingindo 100%, eventos de out-of-memory (OOM), falhas, failovers primário/standby, eventos de HA, instruções Prepare não fechadas, instruções SQL longas, Triggers e problemas no Query Parser.

Cenário 1: OOM (out-of-memory) causando falha na instância

Causa: Conexões excessivas (grande número de conexões ociosas) e instruções Prepare não fechadas em tempo hábil levam ao uso excessivo de memória, eventualmente disparando um evento OOM e causando a falha da instância.

Soluções:

• No lado da aplicação, recicle conexões ociosas prontamente.

• Feche instruções Prepare em tempo hábil e investigue a causa raiz das iniciações concorrentes de Prepare.

• Faça upgrade para uma versão secundária mais recente do mecanismo durante horários de baixa demanda para aproveitar as otimizações de memória no nível do kernel.

• Tente reduzir o valor do parâmetro innodb_buffer_pool_size e observe se o problema melhora.

Cenário 2: Concentração de memória do Query Parser causando crescimento sustentado de memória ou failover primário/standby

Causa: Instruções SQL longas e Triggers grandes causam alto consumo de memória pelo Parser. Observe o seguinte:

• Mesmo que uma instrução SQL específica tenha sido otimizada ou não seja roteada para o nó de escrita, outras instruções SQL longas ou Triggers ainda podem disparar o problema.

• Operações DML devem ser executadas no nó primário, independentemente de qualquer configuração de divisão de leitura/escrita.

Soluções:

• Divida instruções SQL longas em múltiplas instruções mais curtas.

• Otimize Triggers ou reduza seu tamanho.

• Controle o comprimento do SQL no nível da aplicação.

• Se necessário, aumente as especificações da instância ou ajuste o parâmetro innodb_buffer_pool_size.

Cenário 3: SQL com exame extenso causando uso de memória de 100% e disparando failover primário/standby (não refletido em relatórios de diagnóstico)

Causa: Instruções SQL com exame extenso — como consultas com condições complexas ou agregações COUNT — consomem grandes quantidades de memória. Essas instruções podem não aparecer em relatórios de diagnóstico, dificultando sua detecção.

Soluções:

• Analise o log de consultas lentas para identificar instruções SQL específicas com exame extenso.

• Otimize as instruções SQL identificadas adicionando índices apropriados ou reescrevendo as consultas.

Bugs do sistema

Bugs do sistema são uma causa relativamente rara de problemas de alta CPU. Exemplos de versões anteriores incluem deadlocks de processos e full table scans causados pela redefinição das estatísticas da tabela para zero. Com a evolução do product, problemas de CPU causados por bugs do sistema tornaram-se menos comuns. No entanto, solucionar esses problemas frequentemente exige informações profundas do nível do kernel e pode ser difícil de resolver por conta própria. Recomendamos que você contact us para obter suporte técnico.