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 solucionar os problemas.

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

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

Prazo e filosofia de repetição do Spanner

A filosofia de prazo e repetição do Spanner é diferente de muitas outras sistemas. No Spanner, especifique um prazo de tempo limite como o tempo máximo em que uma resposta é útil. Definir uma configuração prazo curto, apenas para repetir imediatamente a mesma operação de novo não é recomendado, pois isso levará a situações em que as operações nunca serão concluídas. Em nesse contexto, as estratégias e operações a seguir não são recomendadas: elas contraprodutivas e impedem a repetição interna do Spanner comportamento:

  • 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 tempo limite. Em vez disso, estabeleça um prazo que seja a quantidade máxima de tempo em que uma resposta é útil.

  • Definir um prazo muito longo e cancelar a operação antes do o prazo é ultrapassado. Isso leva a novas tentativas e desperdício de trabalho em cada tentativa. Em agregado, o que pode criar uma carga adicional significativa em 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, do marshalling, do unmarshalling, e aplicação de prazos. Os prazos permitem que seu aplicativo especifique quanto tempo ela está disposta a aguardar a conclusão de uma solicitação antes que ela seja encerrada com erro de prazo excedido.

O guia de configuração de tempo limite demonstra como especificar prazos (ou tempos limite) em cada um dos serviços do Spanner bibliotecas de cliente. As bibliotecas de cliente do Spanner usam o tempo limite padrão e de nova tentativa, que sã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 DEADLINE_EXCEEDED erros para os seguintes tipos de problemas:

Problemas com a API de acesso a dados

Uma instância do Spanner precisa ser configurada corretamente para cargas de trabalho específicas para evitar problemas de API de acesso aos dados. As seções a seguir descrever 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 o uso da CPU passa da o limite íntegro recomendado. Você pode conferir o uso da CPU do Spanner no console de monitoramento no console do Google Cloud. Também é possível criar alertas com base no uso da CPU da instância.

Resolução

Para saber como reduzir o uso da CPU da instância, consulte como reduzir a utilização da CPU.

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

À medida que a solicitação sai do cliente e volta para os servidores do Spanner, há vários saltos de rede que precisam ser feitos: da biblioteca de cliente para Google Front End (GFE) do GFE para o front-end da API Spanner e, por fim, do front-end da API Spanner para o no banco de dados do Spanner. Se houver problemas de rede em qualquer um desses você 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

Uma vez que o detalhamento da latência seja obtido, é possível usar métricas para diagnosticar a latência, entender por que isso está acontecendo e encontrar soluções.

Problemas com a API Data

Alguns 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 para verificar esses padrões de uso não ideais.

Verificar se há consultas caras

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

Você pode 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 de execução lenta, como como o número médio de linhas lidas, a média de bytes lidos, o número médio de de linhas verificadas e muito mais. Além disso, você pode gerar planos de execução de consulta para inspecionar mais detalhadamente a execução das consultas.

Resolução

Para otimizar suas consultas, use o guia de práticas recomendadas para consultas SQL. Você também pode usar os dados das tabelas de estatísticas mencionadas e planos de execução para otimizar as consultas e fazer alterações no esquema aos seus bancos de dados. Essas práticas recomendadas podem ajudar a reduzir o tempo de execução as declarações, podendo ajudar a acabar com os erros de prazo excedido.

Verificar a contenção de bloqueio

As transações do Spanner precisam adquirir bloqueios. a fazer commit. Aplicativos executados em alta capacidade de processamento podem fazer com que pelos mesmos recursos, o que gera uma espera maior para obter os bloqueios e o que afeta o desempenho geral. Isso pode resultar em prazos excedidos solicitações de leitura ou gravação.

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

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 uma 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 contenções de bloqueio. Além disso, use transações somente leitura. para casos de uso de leitura simples para evitar conflitos de bloqueio com as gravações. Usando transações de leitura/gravação devem ser reservadas para gravações ou fluxos de trabalho de leitura/gravação mistos. Siga estas etapas para melhorar a latência geral da sua transação. tempo de execução e reduzir erros de prazo excedido.

Verificar se há esquemas não otimizados

Antes de projetar um esquema de banco de dados ideal para o Spanner você deve considerar os tipos de consultas que serão executadas em seu banco de dados. Esquemas abaixo do ideal podem causar problemas de desempenho na execução 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 ideal vai depender das leituras e gravações feitas seu banco de dados. As práticas recomendadas de criação de esquema e o SQL guias de práticas recomendadas devem ser seguidos, independentemente especificidades do esquema. Ao seguir esses guias, você evita o esquema mais comum problemas de design. Outras causas raiz para o baixo desempenho são atribuídas a sua escolha de chaves primárias, layout de tabela (consulte Como usar tabelas intercaladas para acesso mais rápido) o design do esquema (consulte Como otimizar o esquema para melhorar o desempenho) e o desempenho do nó configurado 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 dos pontos de acesso. Por exemplo, criar monotonicamente aumentar as colunas limita o número de divisões que o Spanner podem trabalhar para distribuir a carga de trabalho de maneira uniforme. Esses gargalos podem resultar nos tempos limite. Além disso, você pode usar o Key Visualizer para solucionar problemas de desempenho causados por pontos de acesso.

Resolução

Consulte as resoluções identificadas na seção anterior Verificar se há erros esquemas como uma primeira etapa para resolver esse problema. Reformule seu esquema de banco de dados e usar índices intercalados para evitar índices que possam causar uso excessivo do ponto de acesso. Se seguir essas etapas mitigar 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 grande alcance, que podem e evitam a divisão baseada em carga.

Verificar se há tempos limite configurados incorretamente

As bibliotecas de cliente oferecem um tempo limite padrão razoável para todas as solicitações no Spanner. No entanto, essas configurações padrão podem precisar ser de acordo com sua carga de trabalho específica. Vale a pena observar o custo do seu consultas e ajustar os prazos de acordo com seu caso de uso.

Resolução

As configurações padrão de tempo limite são adequadas para a maioria dos casos de uso. Os usuários podem modificar essas configurações (consulte o guia personalizado de tempo limite e novas tentativas); mas não é recomendado usar tempos limite mais agressivos que os padrão. Se você decidir alterar o tempo limite, defina-o como o tempo real que o aplicativo está disposto a esperar pelo resultado. É possível testar com tempo limite configurado, mas nunca defina um tempo limite menor que o tempo limite tempo que o aplicativo está disposto a esperar, pois isso faria com que a operação fosse que foram feitas com mais frequência.

Problemas com a API Admin

As solicitações da API Admin são operações caras quando comparadas às solicitações da API de dados. Solicitações de administrador, como CreateInstance, CreateDatabase ou CreateBackups, podem levar muitos segundos antes de retornar uma resposta. Cliente do Spanner as bibliotecas definem prazos de 60 minutos para as instâncias e banco de dados solicitações do administrador. Isso serve para garantir que o servidor tenha a oportunidade de concluir 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 do administrador, verificar se a biblioteca de cliente está atualizada e usando a versão para a versão anterior. Se você acessar a API Spanner diretamente por um biblioteca de cliente que você criou, verifique se não há prazos mais agressivos do que as configurações padrão (60 minutos) da sua instância e banco de dados solicitações do administrador.

Problemas no console do Google Cloud

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

Captura de tela da mensagem de erro "Prazo excedido do console do Google Cloud"

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

Resolução

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

Outro exemplo de erro de prazo excedido do Dataflow é mostrado em esta 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 embaralhamento se ele ainda não estiver ativado. Em segundo lugar, tente ajustar de configuração na leitura do banco de dados, como maxPartitions e partitionSizeBytes. Para mais informações, consulte PartitionOptions. para tentar reduzir o tamanho do item de trabalho. Confira um exemplo de como fazer isso neste modelo do Dataflow.

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

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

  • Uma alta latência do Google Front End, mas baixa latência de solicitação 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: