Nesta página, apresentamos uma visão geral dos erros de prazo excedido do Spanner: o que são, por que ocorrem e como solucionar e resolver esses problemas.
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 dentro do período de tempo limite configurado.
Um erro de prazo excedido pode ocorrer por vários motivos, como instâncias do Spanner sobrecarregadas, esquemas não otimizados ou consultas não otimizadas. Nesta página, descrevemos cenários comuns em que ocorre um erro de prazo excedido e fornecemos 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, 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, porque isso leva 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 contraproducentes e anulam 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 de expirar. 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 ele seja excedido. Isso leva a novas tentativas e desperdício de trabalho em cada uma delas. No total, 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 unmarshaling e da aplicação de prazos. Os prazos permitem que o aplicativo especifique quanto tempo ele está disposto a esperar para que uma solicitação seja concluída 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 configurações padrão de tempo limite e política de repetição, que são definidas nos seguintes arquivos de configuração:
- spanner_grpc_service_config.json
- spanner_admin_instance_grpc_service_config.json
- spanner_admin_database_grpc_service_config.json
Para saber mais sobre os prazos do gRPC, consulte gRPC e prazos.
Como investigar e resolver erros comuns de prazo excedido
Talvez você encontre erros DEADLINE_EXCEEDED para os seguintes tipos de problema:
- Problemas com a API de acesso aos dados
- Problemas com a API Data
- Problemas com a API Admin
- Problemas no console doGoogle Cloud
- Problemas do Dataflow
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 com a API de acesso a dados. As seções a seguir descrevem como investigar e resolver diferentes problemas da API Data Access.
Verificar a carga de CPU da instância do Spanner
A latência da solicitação pode aumentar significativamente quando a utilização da CPU ultrapassa o limite de integridade 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 saber como reduzir o uso da CPU da instância, consulte Como 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 volta, 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, 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, talvez você veja 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 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, é possível 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 do Spanner podem causar erros de prazo excedido. Nesta seção, fornecemos diretrizes sobre como verificar esses padrões de uso não ideais.
Verificar se há 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, correlações em várias tabelas grandes ou uma execução de consulta com um predicado em uma coluna que não é de 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 de execução lenta, como o número médio de linhas lidas, os bytes médios 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 ainda mais 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 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 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. Os aplicativos executados com alta capacidade de processamento podem fazer com que as transações concorram pelos mesmos recursos, o que aumenta a espera para conseguir os bloqueios e afeta o desempenho geral. Isso pode resultar em prazos excedidos para qualquer solicitação de leitura ou gravação.
Para encontrar a causa raiz de transações de leitura e gravação de 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, é possível encontrar 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 estão acessando 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, use transações somente leitura para casos de uso de leituras 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 essas etapas deve 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 de banco de dados ideal para o Spanner, considere os tipos de consultas que serão executadas no banco de dados. 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 ideal depende das leituras e gravações feitas no banco de dados. Os guias de práticas recomendadas para design de esquemas e práticas recomendadas para SQL precisam ser seguidos, independentemente das especificidades do esquema. Ao seguir esses guias, você evita os problemas mais comuns de design de esquema. Outras causas raiz de desempenho ruim são atribuídas à escolha de chaves primárias, ao layout da tabela (consulte Como usar tabelas intercaladas para acesso mais rápido), ao design do esquema (consulte Como otimizar o esquema para desempenho) e ao desempenho do nó configurado na instância do Spanner (consulte a Visão geral do desempenho do Spanner).
Verificar se há superutilizações pontuais
Como o Spanner é um banco de dados distribuído, o design do esquema precisa evitar pontos de acesso. Por exemplo, a criação de colunas que aumentam de forma monotônica limita o número de divisões que o Spanner pode usar para distribuir a carga de trabalho de maneira uniforme. Esses gargalos podem resultar em tempos limite. Além disso, é possível 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 uma primeira etapa para resolver esse problema. Refaça o design do esquema do banco de dados e use índices intercalados para evitar índices que possam causar pontos de acesso. Se essas etapas não mitigarem o problema, consulte o guia para 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 impedir a divisão com base em carga.
Verificar se há tempos limite configurados incorretamente
As bibliotecas de cliente fornecem tempos limite padrão razoáveis para todas as solicitações no Spanner. No entanto, talvez seja necessário ajustar essas configurações padrão para sua carga de trabalho específica. Vale a pena observar o custo das consultas e ajustar os prazos para que sejam adequados ao seu caso de uso específico.
Resolução
As configurações padrão de tempos 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 é recomendável usar tempos limite mais agressivos do que os padrões. Se você decidir mudar o tempo limite, defina-o como o tempo real que o aplicativo está disposto a esperar pelo resultado. É possível testar tempos limite configurados mais longos, mas nunca defina um tempo limite menor do que o tempo real que o aplicativo está disposto a esperar, porque isso faria com que a operação fosse repetida com mais frequência.
Problemas com a API Admin
As solicitações de API Admin são operações caras em comparação com as solicitações de API Data.
As solicitações de administrador, como CreateInstance, CreateDatabase ou CreateBackups, podem
levar muitos segundos antes de 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 ela está atualizada e usando a versão mais recente. Se você estiver acessando a API Spanner diretamente por uma biblioteca de cliente que criou, verifique se não há configurações de prazo mais agressivas do que as configurações padrão (60 minutos) para as solicitações de administrador de instância e banco de dados.
Problemas no console doGoogle Cloud
As consultas emitidas na página do Spanner Studio no console do Google Cloud não podem exceder cinco minutos. Se você criar uma consulta cara que leva mais de cinco minutos para ser executada, a seguinte mensagem de erro será exibida:
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 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 commit. Essas configurações permitem operações mais longas em comparação com os tempos limite de prazo da biblioteca de cliente independente. 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, é possível personalizar a configuração de tempo limite de commit 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 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 embaralhamento, se ainda não estiver ativado. Em segundo lugar, tente ajustar as
configurações 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.
Outros recursos de solução de problemas de prazo excedido
Se você ainda estiver vendo um erro DEADLINE_EXCEEDED depois de concluir as
etapas de solução de problemas, abra um caso de suporte se
você se deparar com os seguintes cenários:
- Uma latência alta do Google Front End, mas uma latência baixa de solicitação da API Spanner
- Uma latência alta de solicitação de API Spanner, mas uma latência baixa de consulta
Você também pode consultar os seguintes recursos de solução de problemas: