Resolva problemas relacionados com erros de prazo excedido do Spanner

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

Ao aceder às APIs Spanner, os pedidos podem falhar devido a erros DEADLINE_EXCEEDED. Este erro indica que não foi recebida uma resposta dentro do período de limite de tempo configurado.

Um erro de prazo excedido pode ocorrer por vários motivos diferentes, 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 fornece um guia sobre como investigar e resolver estes problemas.

Filosofia de repetição e prazo do Spanner

O prazo e a filosofia de repetição do Spanner diferem dos de muitos outros sistemas. No Spanner, deve especificar um prazo de limite de tempo como o tempo máximo em que uma resposta é útil. Não recomendamos que defina um prazo artificialmente curto apenas para tentar novamente a mesma operação imediatamente, uma vez que isto vai originar situações em que as operações nunca são concluídas. Neste contexto, as seguintes estratégias e operações não são recomendadas. São contraproducentes e anulam o comportamento interno de repetição do Spanner:

  • Definir um prazo demasiado curto. Isto significa que a operação não é resiliente a aumentos ocasionais da latência final e não pode ser concluída antes de exceder o tempo limite. Em alternativa, defina um prazo que seja o tempo máximo em que uma resposta é útil.

  • Definir um prazo demasiado longo e cancelar a operação antes de o prazo ser excedido. Isto leva a novas tentativas e a trabalho desperdiçado em cada tentativa. Em conjunto, isto pode criar uma carga adicional significativa na sua instância.

O que é um erro de prazo excedido?

Quando usa uma das bibliotecas de cliente do Spanner, a camada gRPC subjacente encarrega-se da comunicação, da serialização, da desserialização e da aplicação de prazos. Os prazos permitem que a sua aplicação especifique durante quanto tempo está disposta a aguardar pela conclusão de um pedido antes de o pedido ser terminado com o erro de prazo excedido.

O guia de configuração do limite de tempo demonstra como pode especificar prazos (ou limites de tempo) em cada uma das bibliotecas de cliente do Spanner suportadas. As bibliotecas de cliente do Spanner usam as definições predefinidas de tempo limite e política de repetição, que estão definidas nos seguintes ficheiros de configuração:

Para saber mais acerca dos prazos do gRPC, consulte o artigo gRPC e prazos.

Como investigar e resolver erros comuns de prazo excedido

Pode encontrar erros DEADLINE_EXCEEDED para os seguintes tipos de problemas:

Problemas da API de acesso aos dados

Uma instância do Spanner tem de ser configurada adequadamente para as suas cargas de trabalho específicas para evitar problemas com a API de acesso aos dados. As secções seguintes descrevem como investigar e resolver diferentes problemas da API de acesso aos dados.

Verifique a carga da CPU da instância do Spanner

A latência dos pedidos pode aumentar significativamente à medida que a utilização da CPU ultrapassa o limite recomendado. Pode verificar a utilização da CPU do Spanner na consola de monitorização disponibilizada na Google Cloud consola. Também pode criar alertas com base na utilização da CPU da instância.

Resolução

Para ver os passos para reduzir a utilização da CPU da instância, consulte o artigo Reduzir a utilização da CPU.

Verifique a discriminação da latência ponto a ponto do pedido

À medida que um pedido viaja do cliente para os servidores do Spanner e vice-versa, existem vários saltos de rede que têm de ser feitos: da biblioteca 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 a base de dados do Spanner. Se existirem problemas de rede em qualquer uma destas fases, pode ver erros de limite de tempo excedido.

É possível capturar a latência em cada fase. Para saber mais, consulte o artigo Pontos de latência num pedido do Spanner. Para saber onde ocorre a latência no Spanner, consulte o artigo Identifique onde ocorre a latência no Spanner.

Resolução

Depois de obter a discriminação da latência, pode usar métricas para diagnosticar a latência, compreender por que motivo está a ocorrer e encontrar soluções.

Problemas com a API Google Data

Determinados padrões de utilização não ideais da API Data do Spanner podem causar erros de limite de tempo excedido. Esta secção fornece diretrizes sobre como verificar estes padrões de utilização não ideais.

Verifique se existem consultas dispendiosas

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

Pode inspecionar consultas dispendiosas através da tabela de estatísticas de consultas e da tabela de estatísticas de transações. 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 analisadas e muito mais. Além disso, pode gerar planos de execução de consultas para inspecionar mais detalhadamente a forma como as consultas estão a ser executadas.

Resolução

Para otimizar as suas consultas, use o guia de práticas recomendadas para consultas SQL. Também pode usar os dados obtidos através das tabelas de estatísticas mencionadas anteriormente e dos planos de execução para otimizar as suas consultas e fazer alterações ao esquema das suas bases de dados. Estas práticas recomendadas podem ajudar a reduzir o tempo de execução das declarações, o que pode ajudar a eliminar os erros de limite de tempo excedido.

Verifique se há contenção de bloqueios

As transações do Spanner têm de adquirir bloqueios para serem confirmadas. As aplicações executadas com um débito elevado podem fazer com que as transações concorram pelos mesmos recursos, o que provoca um aumento do tempo de espera para obter os bloqueios e afeta o desempenho geral. Isto pode resultar no incumprimento dos prazos para quaisquer pedidos de leitura ou escrita.

Pode encontrar a causa principal das transações de leitura/escrita com latência elevada através da tabela de estatísticas de bloqueios e consultando a seguinte publicação no blogue. Na tabela de estatísticas de bloqueios, pode encontrar as chaves de linhas com os tempos de espera de bloqueio mais elevados.

Este guia de resolução de problemas de conflitos de bloqueio explica como encontrar as transações que estão a aceder às colunas envolvidas no conflito de bloqueio. Também pode descobrir que transações estão envolvidas num conflito de bloqueio através do guia de resolução de problemas com etiquetas de transações.

Resolução

Aplique estas práticas recomendadas para reduzir as contestações de bloqueios. Além disso, use transações só de leitura para exemplos de utilização de leituras simples, de modo a evitar conflitos de bloqueio com as escritas. A utilização de transações de leitura/escrita deve ser reservada para escritas ou fluxos de trabalho mistos de leitura/escrita. Seguir estes passos deve melhorar a latência geral do tempo de execução da transação e reduzir os erros de prazo excedido.

Verifique se existem esquemas não otimizados

Antes de criar um esquema de base de dados ideal para a sua base de dados do Spanner, deve considerar os tipos de consultas que vão ser executados na sua base de dados. Os esquemas abaixo do ideal podem causar problemas de desempenho quando executa algumas consultas. Estes problemas de desempenho podem impedir a conclusão dos pedidos dentro do prazo configurado.

Resolução

O design de esquema mais otimizado depende das leituras e escritas feitas na sua base de dados. Os guias de práticas recomendadas de design de esquemas e práticas recomendadas de SQL devem ser seguidos independentemente das especificidades do esquema. Seguindo estes guias, evita os problemas de design de esquemas mais comuns. Outras causas principais do baixo desempenho são atribuídas à escolha das chaves primárias, ao esquema da tabela (consulte o artigo Usar tabelas intercaladas para um acesso mais rápido), ao design do esquema (consulte o artigo Otimizar o esquema para o desempenho) e ao desempenho do nó configurado na sua instância do Spanner (consulte o artigo Vista geral do desempenho do Spanner).

Verifique se existem pontos ativos

Uma vez que o Spanner é uma base de dados distribuída, a estrutura do esquema tem de ter em conta a prevenção de pontos críticos. Por exemplo, a criação de colunas que aumentam monotonicamente limita o número de divisões com que o Spanner pode trabalhar para distribuir a carga de trabalho de forma uniforme. Estes estrangulamentos podem resultar em limites de tempo. Além disso, pode usar o Key Visualizer para resolver problemas de desempenho causados por pontos críticos.

Resolução

Consulte as resoluções identificadas na secção anterior Verifique se existem esquemas não otimizados como primeiro passo para resolver este problema. Redesenhe o esquema da base de dados e use índices intercalados para evitar índices que possam causar hotspotting. Se seguir estes passos não mitigar o problema, consulte o guia de escolha de uma chave principal para evitar pontos críticos. Por último, evite padrões de tráfego abaixo do ideal, como leituras de grande intervalo, que podem impedir a divisão baseada na carga.

Verifique se existem limites de tempo configurados incorretamente

As bibliotecas cliente fornecem predefinições de tempo limite razoáveis para todos os pedidos no Spanner. No entanto, estas configurações predefinidas podem ter de ser ajustadas para a sua carga de trabalho específica. Vale a pena observar o custo das suas consultas e ajustar os prazos para se adequarem ao seu exemplo de utilização específico.

Resolução

As predefinições para os limites de tempo são adequadas para a maioria dos exemplos de utilização. Os utilizadores podem substituir estas configurações (consulte o guia de repetição e limite de tempo personalizado), mas não é recomendável usar limites de tempo mais agressivos do que os predefinidos. Se decidir alterar o limite de tempo, defina-o para o tempo real que a aplicação está disposta a esperar pelo resultado. Pode experimentar com tempos limite configurados mais longos, mas nunca defina um tempo limite inferior ao tempo real que a aplicação está disposta a esperar, uma vez que isto faria com que a operação fosse repetida com mais frequência.

Problemas da API Admin

Os pedidos da API Admin são operações dispendiosas quando comparados com os pedidos da API Google Data. Os pedidos de administrador, como CreateInstance, CreateDatabase ou CreateBackups, podem demorar vários segundos antes de devolver uma resposta. As bibliotecas do cliente do Spanner definem prazos de 60 minutos para pedidos de administrador da instância e da base de dados. Isto destina-se a garantir que o servidor tem a oportunidade de concluir o pedido antes de o cliente tentar novamente ou falhar.

Resolução

Se estiver a usar a biblioteca cliente do Google Spanner para aceder à API de administrador, certifique-se de que a biblioteca cliente está atualizada e a usar a versão mais recente. Se estiver a aceder à API Spanner diretamente através de uma biblioteca de cliente que criou, certifique-se de que não tem definições de prazo mais agressivas do que as predefinições (60 minutos) para os pedidos de administrador da sua instância e base de dados.

Google Cloud problemas da consola

As consultas emitidas a partir da página do Spanner Studio na Google Cloud consola não podem exceder cinco minutos. Se criar uma consulta dispendiosa cuja execução demore mais de cinco minutos, é apresentada a seguinte mensagem de erro:

Captura de ecrã da mensagem de erro de prazo excedido da consola Google Cloud

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

Resolução

Pode reescrever a consulta através do guia de práticas recomendadas para consultas SQL.

Problemas do Dataflow

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

Resolução

Se ocorrer um erro de prazo excedido nos passos ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, consulte a tabela de estatísticas de consultas para saber que consulta analisou um grande número de linhas. Em seguida, modifique essas consultas para tentar reduzir o tempo de execução.

Outro exemplo de um erro de limite excedido do Dataflow é apresentado 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)

Este limite de tempo excedido ocorreu porque os itens de trabalho são demasiado grandes. No exemplo anterior, as duas recomendações seguintes podem ajudar. Primeiramente, pode tentar ativar o serviço de reprodução aleatória, se ainda não estiver ativado. Em segundo lugar, pode tentar ajustar as configurações na leitura da base de dados, como maxPartitions e partitionSizeBytes. Para mais informações, consulte PartitionOptions para tentar reduzir o tamanho do item de trabalho. Pode encontrar um exemplo de como o fazer neste modelo do Dataflow.

Recursos adicionais de resolução de problemas de prazos excedidos

Se continuar a ver um erro DEADLINE_EXCEEDED depois de concluir os passos de resolução de problemas, abra um registo de apoio técnico se tiver os seguintes cenários:

  • Uma latência elevada do front-end da Google, mas uma latência baixa do pedido da API Spanner
  • Uma latência de pedido da API Spanner elevada, mas uma latência de consulta baixa

Também pode consultar os seguintes recursos de resolução de problemas: