Resolver erros de prazo excedido do Spanner

Esta página oferece uma visão geral dos erros de limite de tempo excedido do Spanner: o que são, por que ocorrem e como resolver.

Ao acessar as APIs do Spanner, as solicitações podem falhar devido a erros DEADLINE_EXCEEDED. Esse erro indica que uma resposta não foi recebida no período de tempo limite configurado.

Um erro de limite de tempo excedido pode ocorrer por vários motivos, como instâncias do Spanner sobrecarregadas, esquemas não otimizados ou consultas não otimizadas. Esta página descreve cenários comuns em que ocorre um erro de prazo excedido e oferece um guia sobre como investigar e resolver esses problemas.

Filosofia de prazo e nova tentativa do Spanner

A filosofia de prazo e nova tentativa do Spanner é diferente de muitos outros sistemas. No Spanner, é necessário especificar um prazo de timeout como o tempo máximo em que uma resposta é útil. Não é recomendado definir um prazo artificialmente curto apenas para tentar a mesma operação novamente, porque isso leva a situações em que as operações nunca são concluídas. Nesse contexto, as seguintes estratégias e operações não são recomendadas. Elas são contraproducentes e derrotam o comportamento de repetição interna do Spanner:

  • Definir um prazo muito curto. Isso significa que a operação não é resiliente a aumentos ocasionais de latência de cauda e não pode ser concluída antes do tempo limite. Em vez disso, defina um prazo que seja o tempo máximo em que uma resposta é útil.

  • Definir um prazo muito longo e cancelar a operação antes que o prazo expire. Isso leva a novas tentativas e trabalho desperdiado em cada tentativa. Em geral, isso pode criar uma carga adicional significativa na sua instância.

O que é um erro de prazo excedido?

Quando você usa uma das bibliotecas de cliente do Spanner, a camada gRPC subjacente cuida da comunicação, marshalling, unmarshalling e aplicação de prazos. Os prazos permitem que seu aplicativo especifique por quanto tempo ele está disposto a esperar a conclusão de uma solicitação antes que ela seja encerrada com o erro de prazo excedido.

O guia de configuração de tempo limite mostra como especificar prazos (ou tempo limite) em cada uma das bibliotecas de cliente do Spanner com suporte. As bibliotecas de cliente do Spanner usam as configurações de política de tempo limite e repetição padrão, definidas nos seguintes arquivos de configuração:

Para saber mais sobre os prazos do gRPC, consulte gRPC e prazos.

Como investigar e resolver erros comuns de prazo excedido

Você pode encontrar erros DEADLINE_EXCEEDED para os seguintes tipos de problema:

Problemas com a API de acesso aos dados

Uma instância do Spanner precisa ser configurada adequadamente para suas cargas de trabalho específicas para evitar problemas de acesso de dados à API. As seções a seguir descrevem como investigar e resolver diferentes problemas de API de acesso a dados.

Verificar a carga da CPU da instância do Spanner

A latência da solicitação pode aumentar significativamente à medida que a utilização da CPU ultrapassa o limite saudável recomendado. É possível verificar a utilização da CPU do Spanner no console de monitoramento fornecido no console do Google Cloud. Também é possível criar alertas com base na utilização da CPU da instância.

Resolução

Para saber como reduzir o uso da CPU da instância, consulte Reduzir o uso da CPU.

Verificar o detalhamento da latência de ponta a ponta da solicitação

À medida que uma solicitação viaja do cliente para os servidores do Spanner e vice-versa, vários saltos de rede precisam ser feitos: da biblioteca de cliente para o Google Front End (GFE), do GFE para o front-end da API Spanner e, finalmente, do front-end da API Spanner para o banco de dados do Spanner. Se houver problemas de rede em qualquer uma dessas etapas, você poderá receber erros de prazo excedido.

É possível capturar a latência em cada etapa. Para saber mais, consulte Pontos de latência em uma solicitação do Spanner. Para saber onde a latência ocorre no Spanner, consulte Identificar onde a latência ocorre no Spanner.

Resolução

Depois de receber o detalhamento da latência, você pode usar métricas para diagnosticar a latência, entender por que ela está acontecendo e encontrar soluções.

Problemas com a API Data

Alguns padrões de uso não ideais da API Data da Spanner podem causar erros de prazo excedido. Esta seção fornece diretrizes sobre como verificar esses padrões de uso não ideais.

Verificar consultas caras

Tentar executar consultas caras que não são executadas dentro do prazo de tempo limite configurado nas bibliotecas de cliente pode resultar em um erro de limite de tempo excedido. Alguns exemplos de consultas caras incluem, entre outros, verificações completas de uma tabela grande, junções cruzadas em várias tabelas grandes ou uma execução de consulta com um predicado em uma coluna que não é chave (também uma verificação completa da tabela).

É possível inspecionar consultas caras usando a tabela de estatísticas de consulta e a tabela de estatísticas de transação. Essas tabelas mostram informações sobre consultas e transações lentas, como o número médio de linhas lidas, a média de bytes lidos, o número médio de linhas verificadas e muito mais. Além disso, é possível gerar planos de execução de consulta para inspecionar melhor como as consultas estão sendo executadas.

Resolução

Para otimizar suas consultas, use o guia de práticas recomendadas para consultas SQL. Você também pode usar os dados obtidos pelas tabelas de estatísticas mencionadas anteriormente e os planos de execução para otimizar as consultas e fazer mudanças de esquema nos seus bancos de dados. Essas práticas recomendadas podem ajudar a reduzir o tempo de execução das instruções, o que pode ajudar a eliminar os erros de prazo excedido.

Verificar a contenção de bloqueio

As transações do Spanner precisam adquirir bloqueios para serem confirmadas. Aplicativos executados com alta taxa de transferência podem fazer com que as transações competam pelos mesmos recursos, causando uma espera maior para conseguir os bloqueios e impactando a performance geral. Isso pode resultar em prazos excedidos para qualquer pedido de leitura ou gravação.

Para encontrar a causa raiz das transações de leitura e gravação com alta latência, use a tabela de estatísticas de bloqueio e confira a postagem do blog a seguir. Na tabela de estatísticas de bloqueio, você encontra as chaves de linha com os tempos de espera de bloqueio mais altos.

Este guia de solução de problemas de conflitos de bloqueio explica como encontrar as transações que estão acessando as colunas envolvidas no conflito de bloqueio. Você também pode descobrir quais transações estão envolvidas em um conflito de bloqueio usando o guia de solução de problemas com tags de transação.

Resolução

Aplique estas práticas recomendadas para reduzir a contenção de bloqueios. Além disso, use transações somente leitura para casos de uso de leitura simples para evitar conflitos de bloqueio com as gravações. O uso de transações de leitura e gravação deve ser reservado para gravações ou fluxos de trabalho mistos de leitura e gravação. Seguir estas etapas melhora a latência geral do tempo de execução da transação e reduz os erros de prazo excedido.

Verificar se há esquemas não otimizados

Antes de projetar um esquema de banco de dados ideal para o banco de dados do Spanner, considere os tipos de consultas que serão executadas no banco de dados. Esquemas subótimos podem causar problemas de desempenho ao executar algumas consultas. Esses problemas de desempenho podem impedir que as solicitações sejam concluídas no prazo configurado.

Resolução

O design de esquema mais ideal vai depender das leituras e gravações feitas no banco de dados. Os guias de práticas recomendadas para a concepção de esquemas e práticas recomendadas de SQL devem ser seguidos, independentemente das especificações do esquema. Ao seguir esses guias, você evita os problemas mais comuns de design de esquemas. Algumas outras causas da baixa performance são atribuídas à sua escolha de chaves primárias, o layout de tabelas (consulte usar tabelas intercaladas para acesso mais rápido), o design do esquema (consulte otimizar o esquema para performance) e a performance do nó configurado na sua instância do Spanner (consulte Visão geral de desempenho do Spanner).

Verificar se há pontos de acesso

Como o Spanner é um banco de dados distribuído, o design do esquema precisa considerar a prevenção de pontos de acesso. Por exemplo, a criação de colunas monotônicas crescentes limita o número de divisões com que o Spanner pode trabalhar para distribuir a carga de trabalho de maneira uniforme. Esses gargalos podem resultar em tempos limite. Além disso, você pode usar o Key Visualizer para resolver problemas de desempenho causados por pontos de acesso.

Resolução

Consulte as resoluções identificadas na seção anterior Verificar esquemas não otimizados como uma primeira etapa para resolver esse problema. Redesenhe o esquema do banco de dados e use índices intercalados para evitar índices que possam causar pontos de acesso. Se essas etapas não resolverem o problema, consulte o guia de escolha de uma chave primária para evitar pontos de acesso. Por fim, evite padrões de tráfego subótimos, como leituras de intervalos grandes, que podem impedir a divisão baseada no carregamento.

Verificar se há tempos limite configurados incorretamente

As bibliotecas de cliente oferecem padrões de tempo limite razoáveis para todas as solicitações no Spanner. No entanto, talvez essas configurações padrão precisem ser ajustadas para sua carga de trabalho específica. Vale a pena observar o custo das suas consultas e ajustar os prazos para se adequar ao seu caso de uso específico.

Resolução

As configurações padrão de tempo limite são adequadas para a maioria dos casos de uso. Os usuários podem substituir essas configurações (consulte o guia de tempo limite e nova tentativa personalizados), mas não é recomendado usar tempos limite mais agressivos do que os padrões. Se você decidir mudar o tempo limite, defina-o como a quantidade real de tempo que o aplicativo está disposto a aguardar pelo resultado. É possível testar tempos limite configurados mais longos, mas nunca defina um tempo limite mais curto do que o tempo real que o aplicativo está disposto a aguardar, porque isso faria com que a operação fosse repetida com mais frequência.

Problemas com a API Admin

As solicitações da API Admin são operações caras em comparação com as solicitações da API Data. As solicitações de administrador, como CreateInstance, CreateDatabase ou CreateBackups, podem demorar alguns segundos para retornar uma resposta. As bibliotecas de cliente do Spanner definem prazos de 60 minutos para solicitações de administrador de instância e banco de dados. Isso garante que o servidor tenha a oportunidade de concluir a solicitação antes que o cliente tente novamente ou falhe.

Resolução

Se você estiver usando a biblioteca de cliente do Spanner do Google para acessar a API de administrador, verifique se a biblioteca de cliente está atualizada e usando a versão mais recente. Se você estiver acessando a API Spanner diretamente por uma biblioteca de cliente criada, verifique se não há configurações de prazo mais agressivas do que as padrão (60 minutos) para as solicitações de administrador do instância e do banco de dados.

Problemas no console do Google Cloud

As consultas emitidas na página do Spanner Studio do console do Google Cloud não podem ultrapassar cinco minutos. Se você criar uma consulta cara que leva mais de cinco minutos para ser executada, a seguinte mensagem de erro vai aparecer:

Captura de tela da mensagem de erro "O prazo do console do Google Cloud foi excedido"

O back-end vai cancelar a consulta com falha, e a transação pode ser revertida, se necessário.

Resolução

Você pode reescrever a consulta usando o guia de práticas recomendadas para consultas SQL.

Problemas do Dataflow

No Apache Beam, a configuração padrão do tempo limite é de duas horas para operações de leitura e 15 segundos para operações de confirmação. Essas configurações permitem operações mais longas quando comparadas com os tempos limite de vencimento da biblioteca de cliente autônoma. No entanto, ainda é possível receber um erro de tempo limite e de prazo excedido quando os itens de trabalho são muito grandes. Se necessário, é possível personalizar a configuração do tempo limite de confirmação do Apache Beam.

Resolução

Se um erro de prazo excedido ocorrer nas etapas ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, verifique a tabela de estatísticas de consulta para descobrir qual consulta verificou um grande número de linhas. Em seguida, modifique essas consultas para tentar reduzir o tempo de execução.

Outro exemplo de erro de limite de tempo excedido do Dataflow é mostrado na mensagem de exceção a seguir:

exception:
     org.apache.beam.sdk.util.UserCodeException:
     com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED:
     io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after
     3599.999905380s.
     [remote_addr=batch-spanner.googleapis.com/172.217.5.234:443] at
 org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output(GroupAlsoByWindowsParDoFn.java:184)

Esse tempo limite ocorreu porque os itens de trabalho são muito grandes. No exemplo anterior, as duas recomendações a seguir podem ajudar. Primeiro, tente ativar o serviço de reprodução aleatória, se ele ainda não estiver ativado. Em segundo lugar, tente ajustar as configurações na leitura do seu banco de dados, como maxPartitions e partitionSizeBytes. Para mais informações, consulte PartitionOptions para tentar reduzir o tamanho do item de trabalho. Um exemplo de como fazer isso pode ser encontrado neste modelo do Dataflow.

Recursos de solução de problemas de prazo excedido

Se você ainda estiver com um erro DEADLINE_EXCEEDED depois de concluir as etapas de solução de problemas, abra um caso de suporte se você tiver os seguintes cenários:

  • Uma alta latência do Google Front End, mas uma baixa latência de solicitação da API Spanner
  • Uma alta latência de solicitação da API Cloud Spanner, mas uma baixa latência de consulta

Consulte também os seguintes recursos de solução de problemas: