AnalyticDB:Ajuste o desempenho do cluster com informações de monitoramento

Alta utilização média de CPU

A métrica de utilização média de CPU indica o uso médio de CPU em vários nós em um momento específico. Uma utilização média elevada pode comprometer a estabilidade do cluster e tornar consultas e gravações mais lentas. Se esse indicador permanecer alto continuamente, há um risco significativo para o cluster, exigindo otimização imediata.

As causas mais comuns para alta utilização média de CPU incluem:

• Consultas

  O consumo excessivo de CPU por consultas geralmente resulta de SQL ineficiente, como consultas com lógica computacional complexa, grande volume de processamento de dados ou JOINs sem condições que geram produtos cartesianos. Utilize o recurso de diagnóstico para localizar consultas problemáticas:

  • Nos resultados de detecção de SQL ineficiente, consultas de longa duração, que leem grandes volumes de dados, possuem muitos estágios ou consomem muita CPU podem elevar a utilização de CPU do cluster. Analise essas consultas com base nos resultados do diagnóstico ou no plano de execução.

  • A detecção de padrões anormais identifica submissões atípicas sob a perspectiva de modelos de SQL. Assim como no caso de SQL ineficiente, analise padrões que causam alto uso de CPU considerando fatores como volume anormal de leitura de dados, alto consumo de CPU e durações de consulta incomuns. Esses padrões anormais podem aumentar a utilização da CPU.

  • Caso observe alta utilização de CPU em nós de computação ou armazenamento, analise o problema usando os resultados de detecção da camada de computação e da camada de armazenamento do recurso de diagnóstico. A detecção de operadores anormais utiliza detalhes e resumos de operadores para filtrar e identificar aqueles com consumo excessivo de CPU.

• Gravações

  Operações de escrita (incluindo INSERT, UPDATE, DELETE, REPLACE, INSERT OVERWRITE e INSERT INTO SELECT) também consomem recursos de CPU e podem levar a uma alta utilização em nós de armazenamento. Nesse cenário, verifique se métricas de monitoramento como TPS de exclusão, TPS de escrita, TPS de atualização e TPS de carga também apresentam aumento repentino.

  Motivos frequentes para alto consumo de CPU devido a gravações incluem:

  • Chaves primárias longas

    Quando uma chave primária é muito extensa, o índice correspondente torna-se grande e consome mais recursos de CPU durante o processamento de consultas.

  • Instruções DELETE

    Se uma única instrução DELETE WHERE corresponder a muitas linhas, o mecanismo de computação precisará calcular as chaves primárias de todas as linhas correspondentes e enviá-las individualmente aos nós de armazenamento para exclusão. Uma única operação DELETE SQL pode ser amplificada significativamente, resultando em alta utilização de CPU.

  • Instruções UPDATE

    Caso uma única instrução UPDATE WHERE corresponda a diversas linhas, o mecanismo de computação deverá localizar as chaves primárias de todas as linhas afetadas, atualizar os valores dos campos correspondentes e enviar as alterações aos nós de armazenamento para marcar as linhas antigas como excluídas e anexar as novas. Essa amplificação de uma única operação UPDATE SQL pode causar alto consumo de CPU.

  • INSERT OVERWRITE

    Uma operação de carga em lote executa tarefas intensivas em CPU, como análise de dados, classificação por campos de índice clusterizado (se existir) e construção de índices de chave primária e regulares. Cada shard requer um thread dedicado para esse trabalho. Embora exista um limite para operações simultâneas de carga em lote (por exemplo, no máximo duas consultas SQL de carga em lote simultâneas), a utilização de CPU ainda pode ficar elevada porque cada shard precisa de um thread exclusivo para essas tarefas.

  • INSERT INTO SELECT

    Ao gravar uma grande quantidade de dados em pouco tempo, jobs BUILD em segundo plano podem acumular-se, aumentando os dados em tempo real. Se uma consulta envolver esses dados em tempo real, o banco de dados precisará escanear um grande volume deles, pois dados em tempo real não são indexados. Isso leva a uma alta utilização de CPU.

• Build

  Um job BUILD realiza tarefas como criação de índices e criação ou limpeza de partições. Essas atividades podem causar alta utilização de CPU nos nós de armazenamento. Compare a utilização de CPU com o número de jobs BUILD no console para identificar a correlação entre essas duas métricas.

  Nota

  • Para mais informações sobre BUILD, consulte BUILD.

  • Para saber como localizar e analisar o alto uso de recursos causado por jobs BUILD, veja Aumento no número de jobs BUILD.

Assimetria na utilização de CPU

A métrica de utilização máxima de CPU representa o uso de CPU do nó mais ocupado em um determinado momento. Uma diferença grande e persistente entre a utilização máxima e a média indica distribuição desigual de tarefas dentro do cluster, causando assimetria na utilização de CPU. Isso significa que alguns nós estão fortemente carregados enquanto outros têm carga leve. Assimetrias severas (por exemplo, diferença superior a 2x) podem impactar significativamente a estabilidade do cluster e desperdiçar recursos. O motivo é que subtarefas de consultas distribuídas ficam limitadas pelo nó com maior utilização de CPU, impedindo melhorias adicionais de desempenho. Frequentemente, a única solução é expandir o cluster, mesmo que outros nós não estejam altamente utilizados.

Possíveis causas para assimetria na utilização de CPU:

• Assimetria na tabela de origem

  Geralmente ocorre quando a chave de distribuição escolhida durante a criação da tabela não é uniforme, causando diferenças significativas na quantidade de dados entre shards.

  Conforme ilustrado na figura a seguir, uma tabela grande apresenta distribuição desigual. Shard_0 e Shard_1 no Nó de Armazenamento 0 contêm uma grande quantidade de dados, enquanto Shard_2 e Shard_3 no Nó de Armazenamento 1 possuem menos dados. Ao consultar essa tabela, o Nó de Armazenamento 0 provavelmente processará mais dados que o Nó de Armazenamento 1. Isso faz com que a utilização de CPU do Nó de Armazenamento 0 seja persistentemente maior que a do Nó de Armazenamento 1, resultando em assimetria de utilização de CPU.

  

  Para obter informações sobre como diagnosticar assimetria na tabela de origem, consulte Diagnóstico de armazenamento. O recurso de diagnóstico também detecta tabelas assimétricas que ocupam grandes quantidades de espaço em disco para ajudar você a analisar a assimetria de recursos.

• Assimetria de dados intermediários

  A assimetria de dados intermediários difere da assimetria da tabela de origem. Neste cenário, os dados da tabela de origem podem estar distribuídos uniformemente entre os shards, mas a distribuição de valores de um campo específico não é uniforme.

  Ao executar uma consulta de agregação group-by ou usar um campo com distribuição desigual como condição de JOIN, o AnalyticDB for MySQL redistribui os dados entre diferentes nós com base nesse campo. Após a redistribuição, dados com o mesmo valor de campo são enviados para o mesmo nó, o que pode causar assimetria de dados.

  Como mostrado na figura a seguir, uma tabela é distribuída pelo campo 'a'. Como o campo 'a' possui valores uniformes, os dados são distribuídos igualmente entre os nós de armazenamento. No entanto, ao agrupar pelo campo 'b' (group by b), o Nó de Armazenamento 1 envia linhas onde 'b' é 'b1' para o Nó de Computação 1. Para garantir que o Nó de Computação 1 tenha todas as linhas onde 'b' é 'b1', o Nó de Armazenamento 2 também envia suas linhas 'b1' para o Nó de Computação 1, enquanto envia linhas 'b2' para o Nó de Computação 2. Como resultado, o Nó de Computação 1 recebe muito mais linhas que o Nó de Computação 2, criando assimetria de dados. Para cálculos subsequentes, o Nó de Computação 1 consumirá mais recursos do cluster.

  

  Para solucionar a utilização desigual de CPU causada por assimetria de dados intermediários, analise os Resultados de diagnóstico no nível de Estágio da consulta para identificar o problema com precisão.

Alta utilização máxima e utilização média moderada de CPU

Tamanho elevado do resultado da consulta

Causa: Uma única consulta SQL que retorna uma quantidade muito grande de dados pode aumentar a utilização de CPU dos nós de acesso.

Solução: Adicione condições de consulta mais precisas para restringir o escopo de busca e reduzir a quantidade de dados retornados. Alternativamente, utilize consultas paginadas para evitar carregar conteúdo excessivo de uma só vez. Caso precise exportar uma grande quantidade de dados, use tabelas externas.

Alto uso de CPU pelo otimizador

Causa: Quando o número de consultas por segundo (QPS) do cluster é alto e o SQL é complexo, o otimizador pode consumir uma grande quantidade de recursos de CPU.

Solução: Comece habilitando o cache de planos. Após habilitá-lo, observe se a utilização de CPU diminui significativamente. Se não diminuir, abra um ticket para obter suporte técnico.

Gravações envolvendo campos longos

Causa: Quando uma tabela possui gravações envolvendo campos longos, os nós de acesso consomem mais recursos para processar esses campos, levando a uma alta utilização de CPU.

Solução: Execute a seguinte instrução para verificar se há tabelas com gravações de campos longos. Se encontradas, otimize a lógica de negócios dessa tabela limitando o tamanho do campo ou dividindo os campos longos.

SELECT *
FROM 
    (SELECT schema_name,
        table_name,
        column_name,
         cast(json_extract(stats,
        '$.avgSize') AS bigint) AS avg_size
    FROM INFORMATION_SCHEMA.COLUMN_STATISTICS ) tmp
ORDER BY  avg_size DESC limit 20;

Alto throughput de E/S de disco

O throughput de E/S de disco indica a capacidade da mídia de armazenamento subjacente, medida em MB/s. Para o valor máximo, consulte ESSD. Esse limite superior é um valor teórico obtido em testes sob condições ideais e pode não refletir a carga real do cluster. Normalmente, a carga real atinge cerca de 80% desse valor nominal.

Alto IOPS de disco

O IOPS de disco indica o número de operações de E/S por segundo na mídia de armazenamento subjacente. Para o valor máximo de IOPS de disco, consulte ESSD. Esse limite superior é um valor teórico obtido em testes sob condições ideais e pode não refletir a carga real do cluster. Normalmente, a carga real atinge cerca de 80% desse valor nominal.

Alta utilização de memória de computação

Bancos de dados analíticos consomem uma quantidade significativa de recursos de memória ao realizar computações de dados em larga escala. Consultas SQL intensivas em memória tipicamente incluem operadores de agregação, topN, janela e junção:

• Operador de agregação

  Um operador de agregação consome muita memória principalmente porque o AnalyticDB for MySQL armazena temporariamente informações de agrupamento na memória. Se o campo de agrupamento tiver muitos valores únicos, uma grande quantidade de memória será consumida no estágio final da agregação distribuída. O estágio parcial consome menos memória porque não requer agregação global; cada nó pode enviar dados para nós downstream após concluir a agregação local em um subconjunto de dados.

• Operador TopN

  Quando o AnalyticDB for MySQL executa um cálculo TopN (por exemplo, em uma consulta SQL com ORDER BY id LIMIT m,n), o operador TopN no AnalyticDB for MySQL armazena em cache uma grande quantidade de dados na memória para completar a ordenação global final se o valor de m for grande. Esse processo consome uma grande quantidade de recursos de memória.

• Operador de janela

  Um operador de janela é usado para calcular funções de janela. Semelhante a um operador de agregação, ele precisa armazenar temporariamente uma grande quantidade de dados na memória para alcançar o resultado semântico final.

• Operador de junção

  O AnalyticDB for MySQL suporta operações de consulta JOIN padrão. O sistema normalmente usa algoritmos de hash e índice para implementar o processo de junção. Para mais informações, consulte Operadores. O algoritmo de hash armazena em cache a tabela menor (a tabela de construção) na memória e cria uma tabela hash para ela a fim de acelerar o processo de junção. Os seguintes fatores podem fazer com que a tabela hash ocupe uma grande quantidade de memória:

  • A própria tabela de construção é grande:

    O AnalyticDB for MySQL usa estatísticas para estimar o tamanho das tabelas em ambos os lados de uma operação JOIN e escolhe a menor como tabela de construção. No entanto, ainda é possível que a tabela de construção seja grande.

  • Estatísticas desatualizadas ou imprecisas:

    Se as tabelas em uma operação JOIN não forem tabelas de origem, mas sim o resultado de múltiplas agregações, filtros ou outras junções, é difícil estimar seus tamanhos com precisão com base nas estatísticas da tabela de origem. Além disso, se as estatísticas estiverem desatualizadas, uma tabela maior pode ser incorretamente escolhida como tabela de construção e usada para criar a tabela hash. Para mais informações, consulte Estatísticas.

  • Left Join:

    Devido a requisitos semânticos, a tabela à direita de um LEFT JOIN deve ser usada para construir a tabela hash a fim de garantir o resultado correto. Se a tabela à direita de um LEFT JOIN for grande, a operação de junção consumirá uma grande quantidade de memória.

Para mais informações sobre esses operadores, consulte Operadores.

Quando há alta concorrência de consultas SQL contendo esses operadores, ou quando um único operador consome uma grande quantidade de memória, a métrica de utilização de memória de computação aumenta. Isso pode afetar a estabilidade do cluster e causar erros de consulta. Erros comuns incluem:

• Query exceeded reserved memory limit: Uma consulta usou mais memória do que seu limite em um único nó.

• Query exceeded system memory pool limit: Um único campo é muito longo ou muitas colunas estão envolvidas na computação.

• Out of Memory Pool size pre cal. available: O pool de memória física está esgotado.

• The cluster is out of memory, and your query was killed: Quando o cluster fica sem memória, ele encerra a maior consulta em execução no momento.

Para reduzir a utilização de memória de computação, ajuste as consultas SQL que contêm esses tipos de operadores. Para instruções detalhadas, consulte Resultados de diagnóstico no nível de Operador.

Aumento no número de jobs BUILD

Um job BUILD constrói principalmente índices para dados gravados, limpa dados expirados e executa tarefas DDL assíncronas. Esse processo transforma dados de um estado otimizado para gravação para um estado otimizado para leitura. Em alguns casos, jobs BUILD podem consumir altos recursos de CPU e E/S de disco em nós de armazenamento, o que pode afetar outras operações e levar a problemas de estabilidade do cluster. A tabela a seguir descreve as métricas de BUILD.

Se um aumento no número de jobs BUILD afetar a utilização de CPU dos nós de leitura/gravação, investigue e analise o problema sob as seguintes perspectivas:

• Partições únicas grandes em tabelas particionadas. Quando uma única partição é grande, é mais provável que receba gravações, atualizações ou exclusões, o que aciona mais facilmente um BUILD nessa partição. Use o Diagnóstico de armazenamento para localizar esses tipos de tabelas e otimizar sua estrutura.

• Tabelas não particionadas muito grandes também são uma causa comum. Quando uma tabela não particionada é grande, também é mais provável que esteja envolvida em gravações, atualizações ou exclusões, o que pode facilmente acionar um BUILD de tabela completa.

• Um grande número de solicitações de leitura e gravação causa utilização sustentada e alta de CPU em nós de armazenamento, o que, por sua vez, desacelera a execução de jobs BUILD.

Aumento no número de nós offline

Quando nós dentro de um cluster AnalyticDB for MySQL ficam indisponíveis, eles ficam offline. Falhas de nó degradam a estabilidade do cluster, causando consultas e gravações mais lentas, bem como erros de consulta. Quando um nó ficar offline, analise se a utilização de CPU está persistentemente alta ou se métricas relacionadas a E/S estão consistentemente em seus limites.

Curvas P95

O AnalyticDB for MySQL fornece curvas de monitoramento P95 para métricas como utilização de CPU, utilização de CPU do nó de acesso, utilização de memória de computação, throughput de E/S de disco, IOPS de disco, utilização de E/S de disco e tempo de espera de E/S de disco. A métrica P95 representa o valor no qual ou abaixo do qual 95% das observações caem. Por exemplo, considere a utilização de CPU dos nós de computação. Se um cluster tem 100 nós de computação, a utilização de CPU de todos os nós é classificada em ordem crescente em um determinado momento. A utilização de CPU do 95º nó é a utilização P95 de CPU para nós de computação.

As diferenças entre valores máximos, médios e P95 são as seguintes:

• O valor máximo simplesmente indica o limite superior dos dados. Na presença de outliers ou valores extremos, o valor máximo de uma métrica de monitoramento pode ser influenciado por esses pontos individuais e pode não representar com precisão a condição geral ou típica do conjunto de dados.

• O valor médio visa descrever a tendência central dos dados, mas pode não refletir com precisão o estado geral se o conjunto de dados contiver outliers ou tiver uma distribuição assimétrica.

• O valor P95 foca no desempenho da porção superior dos dados, ignorando os pontos de dados mais extremos. É adequado para avaliar desempenho ou níveis na maioria das situações.

Aumento no tempo de resposta da consulta

A métrica de tempo de resposta da consulta representa o tempo desde o envio da consulta, passando pelo enfileiramento, até a conclusão da execução. Para mais informações sobre o tempo de execução no AnalyticDB for MySQL, consulte FAQ de Monitoramento.

Um aumento repentino no tempo de resposta das consultas do cluster pode ser causado pelos seguintes fatores:

• SQL ineficiente

  SQL ineficiente consome uma grande quantidade de recursos do cluster, afetando a execução de outras consultas SQL.

• Padrões anormais

  Padrões anormais podem se manifestar de duas maneiras: uma consulta de baixo recurso é executada com frequência muito alta, ou uma consulta de alto recurso cria um gargalo de desempenho para todo o cluster. Isso acaba afetando outras consultas e aumentando o tempo geral de resposta das consultas.

• Aumento no volume de gravações

  Um volume maior de gravações consome mais recursos de CPU e E/S de disco, aciona mais jobs BUILD e, finalmente, leva a um aumento no tempo geral de resposta das consultas.

Na página Informações de Monitoramento no console, selecione o intervalo de tempo em que o tempo de resposta da consulta aumentou e execute diagnósticos para analisar a causa específica com base nos vários resultados de diagnóstico.

Aumento no tempo de espera da consulta

Quando uma consulta é enviada a um nó de acesso, o cluster determina se deve enfileirar a consulta com base nas configurações de tamanho da fila da camada de acesso. Isso evita que muitas consultas SQL sejam executadas simultaneamente, o que poderia aumentar a pressão no cluster e afetar a estabilidade geral. Para mais informações, consulte Controle de concorrência.

Um aumento repentino no tempo de espera da consulta geralmente é causado por uma diminuição na eficiência de execução interna do cluster. Isso pode ocorrer devido a SQL ineficiente ou padrões anormais consumindo uma grande quantidade de recursos do cluster. Use diagnósticos para verificar os resultados multidimensionais de detecção de SQL ineficiente e detecção de padrões anormais. Um aumento na quantidade de dados sendo gravados, que consome mais recursos de CPU e E/S em nós de armazenamento, também pode levar a tempos de espera de consulta mais longos.

Aumento na taxa de falha de consulta

A métrica de taxa de falha de consulta conta apenas a proporção de consultas falhas e não fornece os motivos da falha. Falhas de consulta podem ter múltiplas causas. Causas comuns e soluções são as seguintes:

• Falha de consulta devido a problemas na instrução SQL

  • Erro de sintaxe

    A instrução SQL não está em conformidade com a sintaxe SQL definida pelo AnalyticDB for MySQL. Um erro geralmente é relatado durante o estágio de análise SQL. Exemplos incluem instruções SQL incompletas, formatação incorreta e palavras-chave ou pontuação ausentes.

  • Erro semântico

    A instrução SQL está em conformidade com a sintaxe SQL definida pelo AnalyticDB for MySQL, mas um erro em um objeto de banco de dados é encontrado durante a verificação semântica. Um erro é relatado durante o estágio de análise semântica. Exemplos incluem nome de tabela incorreto, coluna inexistente, campo GROUP BY ausente ou tipo de parâmetro de função incorreto.

• Falha de consulta devido a problemas internos do cluster

  • Timeout de consulta

    O AnalyticDB for MySQL possui um timeout padrão de consulta. Você também pode configurar um timeout de consulta com base nas necessidades do seu negócio. Se o tempo de execução de uma consulta exceder esse limite, a consulta falhará.

    Nota

    • Para informações sobre o timeout padrão de consulta, consulte Limites.

    • Para saber como modificar o timeout de consulta, consulte Parâmetros de configuração Config e Hint.

  • Alta pressão no cluster

    Quando o cluster experimenta alta pressão, timeouts de comunicação interna entre nós ou falhas de processos internos podem causar falhas de consulta.

• Somente leitura

  Quando o sistema detecta um problema com o log Raft, ele define imediatamente o estado do processo como somente leitura. Nesse estado, operações de gravação falharão.

• Timeout

  Se o sistema não conseguir consumir a fila de logs Raft a tempo (por exemplo, devido a gravações lentas causadas por chaves primárias longas), ocorre contrapressão, que eventualmente desacelera a velocidade de gravação e causa erros de timeout.

Quantidade de dados lidos das tabelas

No AnalyticDB for MySQL, os dados são armazenados em diferentes nós de armazenamento. A métrica Quantidade de dados lidos das tabelas mostra a quantidade total de dados retornados da camada de armazenamento para a camada de computação por todas as consultas SQL em um momento específico.

Conforme mostrado na figura a seguir, em um momento específico (Time_1), 6 consultas SQL (query1, query2, query3, query4, query5 e query6) leem dados de 6 tabelas (user, report, customer, test, region e partition). Neste momento, a quantidade total de dados lidos das tabelas é 20.1 GB (calculado como 1.6 + 2 + 3 + 0.7 + 4.8 + 8 = 20.1 GB). A quantidade média de dados lidos das tabelas é 6.7 GB (calculado como total de dados lidos de todos os nós de armazenamento / número de nós de armazenamento, que é (1.6 + 2 + 3 + 0.7 + 4.8 + 8) / 3 = 6.7 GB). A quantidade máxima de dados lidos das tabelas é 12.8 GB (calculado como 4.8 + 8 = 12.8 GB).



Os valores totais, máximos e médios de dados lidos das tabelas podem refletir, até certo ponto, a pressão das consultas SQL sobre o cluster.

• Quando a quantidade média de dados lidos das tabelas aumenta repentinamente, indica que uma grande quantidade de dados está sendo enviada da camada de armazenamento para a camada de computação para processamento, o que consome mais recursos de CPU e memória. Ao mesmo tempo, o aumento na quantidade de dados lidos da camada de armazenamento também consome mais recursos de E/S de disco.

• Quando há uma grande diferença entre as quantidades máxima e média de dados lidos das tabelas, indica que a quantidade de dados sendo lida de diferentes nós de armazenamento varia. Essa diferença na carga de processamento de dados pode fazer com que alguns nós atinjam seus gargalos de recursos prematuramente, o que, por sua vez, afeta o desempenho geral do cluster. Essa situação é frequentemente causada por design de tabela subótimo, como escolher uma chave de distribuição desigual para algumas tabelas, levando a uma distribuição desigual de dados em vários nós de armazenamento.

Métricas relacionadas a gravações

Aumento nos tempos de resposta de gravação, exclusão e atualização

As métricas de tempo de resposta de gravação, tempo de resposta de exclusão e tempo de resposta de atualização indicam o tempo necessário para processar cada linha para operações INSERT INTO VALUES, DELETE e UPDATE, respectivamente. Os tempos de resposta são geralmente afetados pelos seguintes fatores:

• Alta utilização de CPU em nós de armazenamento

  Isso pode ser causado por outros fatores, como SQL ineficiente ou aumento no TPS de gravação, exclusão ou atualização.

• Altas métricas de E/S relacionadas a gravações em nós de armazenamento

  Métricas de E/S relacionadas a gravações em nós de armazenamento incluem throughput de E/S de disco e IOPS de disco. Essas métricas podem aumentar pelos seguintes motivos:

  • Aumento no número de jobs BUILD.

  • O sistema executou operações de backup ou dimensionamento.

  Como todas essas operações exigem gravações em disco, elas podem afetar os tempos de resposta relevantes.

  Se os tempos de resposta de gravação continuarem aumentando durante o processamento de dados, recomendamos agendar jobs de processamento de dados em larga escala fora do horário de pico e limitar o número de jobs de gravação simultâneos para reduzir a pressão de E/S de disco.