Diagnosticar e solucionar exceções de tempo limite de requisição no SDK do Azure Cosmos DB para NoSQL Java v4

  • Aplica-se a: ✅ NoSQL

O erro HTTP 408 ocorre se o kit de desenvolvimento de software (SDK) não conseguiu concluir a solicitação antes do tempo limite expirar.

Etapas para solucionar problemas

A lista a seguir contém causas e soluções conhecidas para exceções de tempo limite de solicitação.

Política de timeout de ponta a ponta

Há cenários em que 408 erros de tempo limite de rede ocorrem mesmo quando todas as soluções preemptivas aqui são implementadas. Uma prática recomendada geral para reduzir a latência final e melhorar a disponibilidade nesses cenários é implementar a política de tempo limite de ponta a ponta. A latência final é reduzida com falha mais rápida e as unidades de solicitação e os custos de computação do lado do cliente são reduzidos interrompendo as tentativas após o tempo limite. A duração do tempo limite pode ser definida em CosmosItemRequestOptions. Em seguida, as opções podem ser passadas para qualquer solicitação enviada ao Azure Cosmos DB para NoSQL:

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();

CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);

container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

Problemas existentes

Se você estiver vendo solicitações ficam paralisadas por um período mais longo ou o tempo limite expirando com mais frequência, atualize o Java v4 SDK para a versão mais recente. OBSERVAÇÃO: É altamente recomendável usar a versão 4.18.0 e superior. Confira as notas de versão do SDK do Java v4 para obter mais detalhes.

Alta utilização da CPU

A alta utilização da CPU é o caso mais comum. Para ter uma latência ideal, o uso da CPU deve ser de aproximadamente 40%. Use 10 segundos como o intervalo para monitorar a utilização máxima (não média) da CPU. Picos de CPU são mais comuns com consultas entre partições, em que pode haver várias conexões para uma mesma consulta.

Solução

O aplicativo cliente que usa o SDK deve ser expandido ou escalado verticalmente.

Limitação de conexão

A limitação de conexão pode acontecer devido a um limite de conexão em um computador host ou ao esgotamento da porta SNAT (conversão de endereço de rede de origem do Azure).

Limite de conexão em um computador host

Alguns sistemas Linux, como o Red Hat, têm um limite superior no número total de arquivos abertos. Soquetes no Linux são implementados como arquivos, portanto, esse número também limita o número total de conexões. Execute o comando a seguir.

ulimit -a

Solução

O número máximo de arquivos abertos permitidos, identificados como nofile, precisa ser de pelo menos 10.000 ou mais. Para obter mais informações, consulte as dicas de desempenho do Java SDK do Azure Cosmos DB para NoSQL v4.

A disponibilidade do soquete ou da porta pode estar baixa

Quando sua solução está em execução no Azure, os clientes que usam o SDK do Java podem atingir o esgotamento da porta SNAT do Azure.

Solução 1

Se você está executando em VMs do Azure, siga o Guia de esgotamento da porta SNAT.

Solução 2

Se você estiver executando o Serviço de Aplicativo do Azure, siga o guia de solução de problemas de conexão e use o diagnóstico do Serviço de Aplicativo.

Solução 3

Se você estiver executando no Azure Functions, verifique se está seguindo a recomendação do Azure Functions de manter clientes de banco de dados individual ou estáticos para todos os serviços envolvidos (incluindo o Azure Cosmos DB for NoSQL). Verifique os limites de serviço com base no tipo e no tamanho de sua hospedagem do Aplicativo de Funções.

Solução 4

Se você usar um proxy HTTP, certifique-se que pode suportar o número de conexões configuradas no SDK GatewayConnectionConfig. Caso contrário, você enfrentará problemas de conexão.

Criar várias instâncias de cliente

A criação de várias instâncias de cliente pode levar a problemas de conflitos de conexão e tempo limite.

Solução 1

Siga as dicas de desempenho e use uma única instância do CosmosClient em um aplicativo inteiro.

Solução 2

Caso não seja possível ter singleton CosmosClient em um aplicativo, recomendamos o uso de compartilhamento de conexão entre vários clientes do Azure Cosmos DB para NoSQL por meio desta API connectionSharingAcrossClientsEnabled(true) no CosmosClient. Quando você tem várias instâncias do cliente interagindo com várias contas, habilitar essa configuração permite o compartilhamento de conexão no modo Direto . Esse modo só será habilitado se o compartilhamento de conexão for possível entre instâncias do cliente NoSQL do Azure Cosmos DB. Observe que, ao definir essa opção de compartilhamento, a configuração de conexão (por exemplo, configuração de tempo limite de soquete, configuração de tempo limite ocioso) do primeiro cliente instanciado é usada para todas as outras instâncias do cliente.

Chave de partição ativa

O Azure Cosmos DB for NoSQL distribui a taxa de transferência provisionada total uniformemente entre as partições físicas. Quando há uma partição quente, uma ou mais chaves de partição lógica em uma partição física estão consumindo todas as RUs/s (unidades de solicitação por segundo) da partição física. Ao mesmo tempo, as RUs/s em outras partições físicas não são utilizadas. Como sintoma, o total de RU/s consumidos é menor do que o total de RU/s provisionadas no banco de dados ou no contêiner, mas você ainda vê limitações (erros 429) nas solicitações em relação à chave de partição lógica quente. Use a métrica normalizada de consumo de RU para verificar se a carga de trabalho está encontrando uma partição quente.

Solução

Escolha uma boa chave de partição que distribua de maneira uniforme o volume de solicitação e o armazenamento. Saiba como alterar a chave de partição.

Alto grau de simultaneidade

O aplicativo está criando um alto nível de simultaneidade, o que pode levar à contenção no canal.

Solução

O aplicativo cliente que usa o SDK deve ser expandido ou escalado verticalmente.

Solicitações ou respostas grandes

Grandes solicitações ou respostas podem levar ao bloqueio de linha no canal e agravar a contenção, mesmo com um grau relativamente baixo de simultaneidade.

Solução

O aplicativo cliente que usa o SDK deve ser expandido ou escalado verticalmente.

A taxa de falha está dentro do contrato de nível de serviço (SLA) do Azure Cosmos DB for NoSQL

O aplicativo deve ser capaz de lidar com falhas transitórias e tentar novamente quando necessário. Exceções 408 não são repetidas porque, ao criar caminhos, é impossível saber se o serviço criou o item ou não. Enviar o mesmo item novamente para criar causa uma exceção de conflito. A lógica de negócios dos aplicativos do usuário pode ter uma lógica personalizada para lidar com conflitos, o que eliminaria a ambiguidade de um item existente versus um conflito de repetição de criação.

A taxa de falha viola o SLA do Azure Cosmos DB for NoSQL

Entre em contato com o Suporte do Azure.

Conteúdo relacionado

  • Last updated on