Resolver erros de prazo excedido do Spanner

Nesta página, você encontra uma visão geral dos erros de prazo excedido do Spanner: o que são, por que ocorrem e como solucioná-los.

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

Um erro de prazo excedido pode ocorrer por muitos motivos diferentes, como instâncias sobrecarregadas do Spanner, esquemas não otimizados ou consultas não otimizadas. Nesta página, descrevemos cenários comuns em que um erro de prazo excedido acontece e oferecemos um guia sobre como investigar e resolver esses problemas.

Prazo e filosofia de nova tentativa do Spanner

O prazo e a filosofia de nova tentativa do Spanner são diferentes dos de muitos outros sistemas. No Spanner, especifique um prazo de tempo limite como o tempo máximo em que uma resposta é útil. Não é recomendável definir um prazo artificialmente curto apenas para repetir imediatamente a mesma operação novamente, porque isso levará a situações em que as operações nunca são concluídas. Nesse contexto, as estratégias e operações a seguir não são recomendadas. Elas são contraprodutivas e anulam o comportamento interno de nova tentativa 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 que ela expire. Em vez disso, defina um prazo que seja a quantidade máxima de tempo em que uma resposta será útil.

  • Definir um prazo muito longo e cancelar a operação antes que ele termine. Isso leva a novas tentativas e desperdício de trabalho em cada tentativa. De maneira agregada, isso pode criar uma carga adicional significativa na 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, do marshaling, do desmarshalling e da aplicação do prazo. Os prazos permitem que o aplicativo especifique quanto tempo ele está disposto a esperar pela 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 demonstra como especificar prazos (ou tempos limite) em cada uma das bibliotecas de cliente do Spanner compatíveis. As bibliotecas de cliente do Spanner usam as configurações de política de tempo limite e nova tentativa padrão, definidas nos seguintes arquivos de configuração:

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

Como investigar e resolver erros comuns de prazo excedido

É possível encontrar erros DEADLINE_EXCEEDED para os seguintes tipos de problemas:

Problemas da API de acesso a dados

Uma instância do Spanner precisa ser configurada corretamente para suas cargas de trabalho específicas para evitar problemas na API de acesso a dados. As seções a seguir descrevem como investigar e resolver diferentes problemas da 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 o uso da CPU ultrapassa o limite íntegro recomendado. É possível verificar o uso da CPU do Spanner no console de monitoramento fornecido no console do Google Cloud. Também é possível criar alertas com base no uso da CPU da instância.

Resolução

Para conhecer as etapas para reduzir o uso da CPU da instância, consulte Como reduzir a utilização da CPU.

Verifique o detalhamento de latência da solicitação

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

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

Resolução

Depois de analisar o detalhamento da latência, use métricas para diagnosticar a latência, entender por que isso está acontecendo e encontrar soluções.

Problemas da API Data

Certos padrões de uso não ideais da API Data do 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 prazo excedido. Alguns exemplos de consultas caras incluem, entre outros, verificações completas de uma tabela grande, mesclagens cruzadas em várias tabelas grandes ou uma execução de consulta com um predicado em uma coluna sem chave (também uma verificação completa da tabela).

É possível inspecionar consultas caras usando as tabelas de estatísticas de consulta e de estatísticas de transação. Estas tabelas mostram informações sobre consultas e transações de execução lenta, 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. Também é possível usar os dados coletados por meio das tabelas de estatísticas mencionadas anteriormente e dos planos de execução para otimizar as consultas e fazer alterações de esquema nos bancos de dados. Essas práticas recomendadas podem ajudar a reduzir o tempo de execução das instruções, possivelmente ajudando a eliminar erros de prazo excedido.

Verificar a contenção de bloqueio

As transações do Spanner precisam adquirir bloqueios para confirmação. Aplicativos em execução com alta capacidade de processamento podem fazer com que as transações compitam pelos mesmos recursos, aumentando a espera para receber os bloqueios e afetando o desempenho geral. Isso pode resultar em prazos excedidos para solicitações de leitura ou gravação.

É possível encontrar a causa raiz das transações de leitura e gravação de alta latência usando a tabela de estatísticas de bloqueio e consultando a seguinte postagem do blog. Na tabela de estatísticas de bloqueio, você encontra as chaves de linha com os maiores tempos de espera de bloqueio.

Este guia de solução de problemas de conflitos de bloqueio explica como encontrar as transações que acessam as colunas envolvidas no conflito de bloqueio. Também é possível 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 as contenções de bloqueio. Além disso, utilize transações somente leitura em casos de uso de leituras simples a fim de evitar conflitos de bloqueio com as gravações. O uso de transações de leitura/gravação precisa ser reservado para gravações ou fluxos de trabalho mistos de leitura e gravação. Siga essas etapas para melhorar a latência geral do tempo de execução da transação e reduzir os erros de prazo excedido.

Verificar se há esquemas não otimizados

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

Resolução

O design de esquema mais adequado dependerá das leituras e gravações feitas no banco de dados. Os guias de práticas recomendadas de criação de esquemas e de práticas recomendadas de SQL precisam ser seguidos, independentemente das especificações do esquema. Siga estes guias para evitar os problemas mais comuns de design de esquema. Algumas outras causas raiz do desempenho ruim são atribuídas à sua escolha de chaves primárias, ao layout da tabela (consulte Como usar tabelas intercaladas para um acesso mais rápido), ao design do esquema (consulte Como otimizar o esquema para desempenho) e ao desempenho do nó configurado na sua instância do Spanner (consulte Visão geral do desempenho do Spanner).

Conferir se há pontos de acesso

Como o Spanner é um banco de dados distribuído, o design do esquema precisa considerar a prevenção do ponto de acesso. Por exemplo, a criação de colunas monotonicamente crescentes limitará o número de divisões com que o Spanner pode trabalhar para distribuir a carga de trabalho uniformemente. 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 se há esquemas não otimizados como a primeira etapa para resolver esse problema. Reformule o esquema do banco de dados e use índices intercalados para evitar índices que possam causar uso excessivo do ponto de acesso. Se essas etapas não atenuarem o problema, consulte o guia Escolher uma chave primária para evitar pontos de acesso. Por fim, evite padrões de tráfego abaixo do ideal, como leituras de intervalo grande, que podem evitar a divisão baseada em carga.

Verificar se há tempos limite configurados incorretamente

As bibliotecas de cliente fornecem padrões de tempo limite razoáveis para todas as solicitações no Spanner. No entanto, essas configurações padrão podem precisar ser ajustadas para sua carga de trabalho específica. Observe o custo das consultas e ajuste os prazos para que sejam adequados ao 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 personalizado sobre tempo limite e nova tentativa), mas não é recomendado usar tempos limite mais agressivos do que os padrão. Se você decidir alterar o tempo limite, defina-o como o tempo real que o aplicativo está disposto a aguardar pelo resultado. É possível testar tempos limite configurados por mais tempo, mas nunca defina um tempo limite menor 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 de dados. Solicitações de administrador, como CreateInstance, CreateDatabase ou CreateBackups, podem levar muitos segundos até retornar uma resposta. As bibliotecas de cliente do Spanner definem prazos de 60 minutos para solicitações de administrador da instância e do 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 Admin, verifique se a biblioteca de cliente está atualizada e usando a versão mais recente. Se você estiver acessando a API Spanner diretamente por meio de uma biblioteca de cliente criada, verifique se não tem configurações de prazo mais agressivas do que as configurações padrão (60 minutos) para suas solicitações de administrador da 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 exceder cinco minutos. Se você criar uma consulta cara que leve mais de cinco minutos para ser executada, verá a seguinte mensagem de erro:

Captura de tela da mensagem de erro com prazo excedido no console do Google Cloud

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

Resolução

É possível reescrever a consulta usando o guia de práticas recomendadas para consultas SQL.

Problemas do Dataflow

No Apache Beam, a configuração de tempo limite padrão é 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 em comparação com os tempos limite da biblioteca de cliente independente. No entanto, ainda é possível receber erros de tempo limite e prazo excedido quando os itens de trabalho são muito grandes. Se necessário, personalize a configuração do tempo limite de confirmação do Apache Beam.

Resolução

Se ocorrer um erro de prazo excedido 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 prazo excedido do Dataflow é mostrado na seguinte mensagem de exceção:

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 foi atingido 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 ordem aleatória, caso ainda não esteja ativado. Em segundo lugar, você pode tentar ajustar as configurações na leitura do banco de dados, como maxPartitions e partitionSizeBytes. Para saber mais, consulte PartitionOptions para tentar reduzir o tamanho do item de trabalho. Confira um exemplo de como fazer isso neste modelo do Dataflow.

O prazo extra excedeu os recursos de solução de problemas

Se o erro DEADLINE_EXCEEDED persistir depois que você concluir as etapas de solução de problemas, abra um caso de suporte se as seguintes situações acontecerem:

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

Você também pode consultar os seguintes recursos de solução de problemas: