Diagnosticar e resolver problemas no Azure Cosmos DB para NoSQL Java SDK v4 com exceções de tempo de espera do pedido

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

Etapas de solução de problemas

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

Política de tempo de espera de ponta a ponta

Existem cenários em que ocorrem erros de tempo limite de rede 408 mesmo quando todas as soluções preventivas aqui estão implementadas. Uma prática geral recomendada para reduzir a latência final e melhorar a disponibilidade nestes cenários é implementar uma política de tempo limite de ponta a ponta. A latência de cauda é reduzida ao falhar mais rapidamente, e as unidades de pedido e os custos de computação do lado do cliente são reduzidos ao parar as tentativas após o timeout. A duração do time out pode ser definida em CosmosItemRequestOptions. As opções podem então ser passadas para qualquer pedido enviado 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);

Questões existentes

Se estiver a ver pedidos presos por mais tempo ou a expirar com mais frequência, por favor atualize o Java v4 SDK para a versão mais recente. NOTA: Recomendamos vivamente a utilização da versão 4.18.0 e superior. Consulte as notas de atualização do SDK Java v4 para mais detalhes.

Utilização elevada da CPU

A utilização elevada da CPU é o caso mais comum. Para a latência ideal, a utilização 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. Os picos de CPU são mais comuns com consultas entre partições em que pode fazer múltiplas ligações para uma única consulta.

Solução

A aplicação cliente que utiliza o SDK deve ser escalada verticalmente ou horizontalmente.

Limitação da conexão

A limitação de conexão pode ocorrer devido a um limite de conexão numa máquina anfitriã ou à exaustão de portas de tradução de endereços de rede de origem no Azure (SNAT).

Limite de ligação numa máquina anfitriã

Alguns sistemas Linux, como o Red Hat, têm um limite superior para o número total de ficheiros abertos. Os sockets no Linux são implementados como ficheiros, por isso este número limita também o número total de ligações. Execute o seguinte comando.

ulimit -a

Solução

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

A disponibilidade do socket ou da porta pode ser baixa

Quando a sua solução está a correr no Azure, os clientes que usam o Java SDK podem enfrentar esgotamento de portas SNAT do Azure.

Solução 1

Se estiver a executar em VMs do Azure, siga o guia de exaustão de portas SNAT.

Solução 2

Se você estiver executando no Serviço de Aplicativo do Azure, siga o guia de solução de problemas de erros 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 singleton ou estáticos para todos os serviços envolvidos (incluindo o Azure Cosmos DB para NoSQL). Verifique os limites de serviço com base no tipo e tamanho da hospedagem do seu aplicativo de função.

Solução 4

Se você usar um proxy HTTP, verifique se ele 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 resultar em problemas de contenção de conexão e problemas de tempo de espera.

Solução 1

Siga as dicas de desempenho e use uma única instância CosmosClient em toda a aplicação.

Solução 2

Se não for possível ter singleton CosmosClient numa aplicação, recomendamos usar a partilha de ligação entre múltiplos clientes Azure Cosmos DB para NoSQL através desta API connectionSharingAcrossClientsEnabled(true) no CosmosClient. Quando tem múltiplas instâncias do cliente a interagir com várias contas, ativar esta definição permite partilhar a ligação em modo Direto . Este modo só é ativado se for possível partilhar ligações entre instâncias do cliente Azure Cosmos DB para NoSQL. Note que, ao definir esta opção de partilha, a configuração da ligação (por exemplo, configuração de tempo de extinção do socket, configuração de tempo de espera inativa) do primeiro cliente instanciado é usada para todas as outras instâncias do cliente.

Chave de partição quente

O Azure Cosmos DB para NoSQL distribui a taxa de transferência geral provisionada uniformemente entre partições físicas. Quando há uma partição quente, uma ou mais chaves de partição lógicas numa partição física estão a consumir todas as Unidades de Pedido (RU/s) dessa partição física por segundo. Ao mesmo tempo, as RU/s noutras partições físicas estão a ficar sem uso. Como um sintoma, o total de RU/s consumido é inferior ao total de RU/s provisionado na base de dados ou contentor, mas ainda assim vê-se estrangulamento (429 erros) nos pedidos contra a chave de partição ativa. Use a métrica de Consumo Normalizado de RU para verificar se a carga de trabalho está a encontrar uma partição quente.

Solução

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

Elevado grau de simultaneidade

A aplicação está a executar um alto nível de simultaneidade, o que pode levar à contenção no canal.

Solução

A aplicação cliente que utiliza o SDK deve ser escalada verticalmente ou horizontalmente.

Grandes pedidos ou respostas

Grandes solicitações ou respostas podem resultar em bloqueios de fila no canal e exacerbar a contenção, mesmo com um grau relativamente baixo de simultaneidade.

Solução

A aplicação cliente que utiliza o SDK deve ser escalada verticalmente ou horizontalmente.

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

O aplicativo deve ser capaz de lidar com falhas transitórias e tentar novamente quando necessário. Quaisquer exceções 408 não são tentadas novamente porque, nos processos de criação, é impossível saber se o serviço criou o item ou não. Enviar novamente o mesmo item para criar causa uma exceção de conflito. A lógica de negócios das aplicações de utilizador pode incluir mecanismos personalizados de gestão de conflitos, o que resolveria a ambiguidade entre um item existente e um conflito resultante de uma nova tentativa de criação.

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

Entre em contato com o Suporte do Azure.

Conteúdo relacionado

• Diagnostica e resolve problemas quando usas o Azure Cosmos DB para NoSQL Java v4 SDK.
• Aprenda sobre as diretrizes de desempenho para Java v4.