Resolva problemas de latência

Tal como qualquer sistema de base de dados, o Bigtable pode ter problemas de latência. Este documento aborda as causas comuns de problemas de latência no Bigtable e explica como resolvê-los.

Diagnostique e resolva problemas de latência do Bigtable através dos passos de resolução de problemas nas secções seguintes:

Compreenda as causas da latência elevada

Os seguintes fatores contribuem para problemas de latência no Bigtable:

  • Latência do servidor. A medição da latência do servidor começa quando o Bigtable recebe o pedido e termina quando o Bigtable envia o último byte de dados para o cliente. Para pedidos de grandes quantidades de dados, a capacidade do cliente de consumir a resposta pode afetar a latência do servidor.
  • As latências de operação medem o tempo total de processamento completo de uma operação do Bigtable, incluindo todas as novas tentativas. Esta métrica acompanha a viagem de ida e volta do cliente para o Bigtable e de volta para o cliente. A latência da sua aplicação, a ligação de rede, a latência da biblioteca de cliente do Bigtable e as latências do servidor afetam a latência da operação.
  • Os padrões de carga de trabalho e de pedidos podem aumentar a latência não só devido a um problema de infraestrutura, mas também devido a uma alteração no padrão de trabalho que a aplicação pede. Por exemplo, uma consulta de análise dinâmica gerada que analisava anteriormente cem linhas, analisa agora um milhão de linhas devido a uma importação de dados recente ou a uma alteração na lógica da aplicação. Embora o sistema possa estar a funcionar de forma eficiente, o aumento significativo da quantidade de trabalho para uma única operação resulta num tempo de execução mais longo, que o Bigtable considera uma latência mais elevada.

Antes de começar

Para resolver problemas de latência elevada, realize as seguintes tarefas:

  • Ative as métricas do lado do cliente para a sua biblioteca cliente para otimizar o desempenho e resolver problemas.
  • Para minimizar a latência da rede, verifique se a sua aplicação reside na mesma zona que o cluster do Bigtable. Isto reduz a distância da rede entre a sua aplicação e o cluster, o que melhora os tempos de resposta aos pedidos.
  • Reúna as seguintes informações sobre o seu ambiente do Bigtable:
  • Recolha as seguintes informações sobre o seu ambiente do lado do cliente:
  • Reúna as seguintes informações sobre o problema:

Resolva problemas de latência

Se tiver problemas de latência no Bigtable, siga estes passos para resolver o problema:

  1. Verifique a latência do servidor: use a página Monitorização na Google Cloud consola para ver a latência do servidor. Para mais informações, consulte o artigo Monitorize com o Cloud Monitoring. Verifique a latência da sua instância. Se a instância contiver vários clusters, divida a métrica por cluster. Se observar aumentos na latência nos gráficos de latência de leitura ou latência de escrita, ou nas métricas do lado do cliente, siga os passos de resolução de problemas de latência do servidor na secção Resolva problemas de latência do servidor deste documento.
  2. Verifique a latência do cliente: depois de ativar as métricas do lado do cliente, pesquise bigtable.googleapis.com/client no Metrics Explorer do Cloud Monitoring. Reveja as métricas do lado do cliente disponíveis. Se vir um aumento da latência nas métricas do lado do cliente, mas não no servidor, examine a sua aplicação e ligação de rede. Para mais informações, consulte a secção Resolva problemas de latência do cliente deste documento.

O diagrama seguinte mostra o processo de resolução de problemas de aumento da latência no Bigtable:

Fluxograma para resolver problemas de latência do Bigtable.
Figura 1. O processo de resolução de problemas de latência do Bigtable (clique para aumentar).

Resolva problemas de latência do cliente

Siga estes passos para resolver problemas de latência do lado do cliente.

Antes de começar

Antes de iniciar a resolução de problemas de latência do lado do cliente, conclua as seguintes tarefas:

  • Ative as métricas do lado do cliente no Bigtable.
  • Ative a preparação de canais se usar uma versão 2.17.1 ou anterior do cliente Java. A atualização de canais está ativada por predefinição a partir da versão 2.18.0.
  • Itere para determinar o tamanho ideal do conjunto de ligações para a sua carga de trabalho. Os canais inadequados ou excessivos podem causar latências de tentativas elevadas.

Verifique as latências de bloqueio de aplicações

Verifique a métrica Application Blocking Latencies na consola do Google Cloud e realize uma das seguintes ações:

  • Se as latências de bloqueio de aplicações forem elevadas e corresponderem ao aumento da latência comunicado, concentre-se na resolução de problemas do lado do cliente.
  • Se as latências de bloqueio de aplicações forem elevadas e o cliente estiver alojado numa infraestrutura, como o GKE ou o Compute Engine, encaminhe o problema para a equipa de apoio técnico adequada.Google Cloud Google Cloud
  • Se as latências de bloqueio de aplicações forem baixas e a latência de publicação do Bigtable também for baixa, o gargalo de latência encontra-se provavelmente num componente intermédio do caminho de rede ou de tráfego, como a rede ou a interface do Google. Pondere encaminhar o problema para a Google Cloud equipa de rede para receber assistência com uma captura de pacotes completa para identificar o gargalo de estrangulamento da latência.

Resolva as latências de operações elevadas

  1. Se connectivity_error_count for elevado, a aplicação tem problemas em alcançar o frontend da Google. Defina limites de tempo limite de RPC mais baixos para que o pedido possa ser repetido em diferentes canais.
    • Se o limite de tempo do RPC for demasiado baixo, também pode originar latências elevadas das operações. Determine o tempo limite de RPC P99 típico durante as operações normais. Definir um valor de tempo limite de RPC mais próximo desta referência ajuda a otimizar o desempenho.
  2. Se o valor de retry_count for elevado, verifique a etiqueta de estado attempt_latencies. Se as tentativas falharem com erros DEADLINE_EXCEEDED, o prazo do pedido é demasiado curto em comparação com a média attempt_latencies.

Tratar pedidos em fila na thread gRPC

Se nenhuma das métricas exceder a norma, os pedidos podem ficar em fila no thread gRPC. Isto pode ocorrer devido aos seguintes motivos:

  • O tamanho do conjunto de canais é demasiado pequeno e os pedidos ficam em fila nos canais gRPC. Para mais informações, consulte o artigo Pedidos em buffer.
  • A utilização da CPU da VM cliente é elevada. A utilização elevada da CPU também leva à colocação de pedidos em fila no cliente.

Resolva problemas de latência do servidor

Siga estes passos para resolver problemas de latência do lado do servidor.

Determine se o cluster está sobrecarregado

  1. Verifique os gráficos Read requests e Write requests para ver alterações no QPS.
  2. Verifique o gráfico Node count para ver se houve alterações na quantidade de nós.
  3. Verifique os gráficos Read throughput e Write throughput para ver aumentos na largura de banda. Para mais informações, consulte o artigo Compreenda o desempenho.
  4. Para identificar como a CPU é usada pelo perfil da app, pelo método e pela tabela para resolver problemas de desempenho, consulte a publicação no blogue Onde é que o seu cluster do Cloud Bigtable está a gastar a CPU?.
  5. Aumente a contagem de nós no cluster afetado. Para mais informações, consulte os artigos Adicione ou remova nós manualmente e Ajuste de escala automático. Verifique se a utilização média da CPU permanece abaixo do limite recomendado.

Verifique se existem pontos ativos

Um tablet quente usa uma percentagem desproporcionadamente grande da CPU de um nó em comparação com outros tablets associados a esse nó. Esta utilização desequilibrada pode ocorrer devido a um volume elevado inesperado de pedidos a um intervalo de linhas ou a falhas no design do esquema. Esta utilização desequilibrada de nós pode causar latências mais elevadas e atrasos na replicação, conhecidos como hotspots.

  1. Observe os pontos críticos no gráfico.CPU utilization (hottest node) high granularity
  2. Para identificar tablets quentes, use hot tablets ou a ferramenta Key Visualizer.
  3. Ao contrário da utilização excessiva da CPU ao nível do cluster, que pode muitas vezes ser atenuada adicionando mais nós (escalabilidade horizontal), os pontos críticos podem exigir outras técnicas de atenuação. Estas técnicas incluem alterar a forma como cria as chaves das linhas ou alterar o esquema. Para mais informações, consulte a publicação no blogue Elimine pontos críticos no Cloud Bigtable.

Resolva a latência com um baixo número de consultas por segundo

O Bigtable tem o melhor desempenho com tabelas grandes às quais acede com frequência. Se enviar pedidos após um período sem utilização, pode observar uma latência elevada enquanto o Bigtable restabelece as ligações.

  1. Se os gráficos Read requests e Write requests mostrarem um número baixo de CPS, espere tempos de resposta mais lentos.
  2. Mitigue os problemas de início a frio seguindo as práticas recomendadas em Inícios a frio e QPS baixo.

Avalie a eficiência dos pedidos

Avalie a eficiência dos pedidos através das estatísticas de consultas. As estatísticas de consultas mostram a proporção de linhas vistas em relação às linhas devolvidas e de células vistas em relação às células devolvidas, o que indica a eficiência das consultas. Melhore a eficiência dos pedidos revendo os padrões de consulta ou o esquema. Para mais informações, consulte o artigo Obtenha estatísticas de consultas.

Verifique a configuração ou as alterações do perfil da app

Se a contagem de nós e o débito permanecerem inalterados, mas a utilização média da CPU aumentar, isto pode resultar de alterações nas estratégias de replicação ou recolha de lixo. Para mais informações, consulte o artigo Replicação e desempenho. Reverter quaisquer alterações de configuração para replicação ou recolha de lixo.

Encaminhe para o apoio técnico do Bigtable

Se os passos anteriores não resolverem o problema, encaminhe-o para o apoio técnico do Bigtable.

O que se segue?