Partilhar via

Diagnosticar e resolver exceções de tempo limite de pedidos do SDK Java v4 do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

O erro HTTP 408 ocorrerá se o SDK não conseguir concluir o pedido antes de o tempo limite ser atingido.

Passos de resolução de problemas

A lista seguinte contém causas e soluções conhecidas para exceções de tempo limite de pedidos.

Política de tempo limite de ponta a ponta

Há cenários em que 408 erros de tempo limite de rede ocorrerão mesmo quando todas as soluções preventivas mencionadas abaixo tiverem sido implementadas. Uma prática recomendada geral para reduzir a latência final, bem como melhorar a disponibilidade nesses cenários, é implementar a política de tempo limite de ponta a ponta. A latência final é reduzida ao falhar mais rapidamente, e as unidades de solicitação e os custos de computação do lado do cliente são reduzidos interrompendo as novas tentativas após o tempo limite. A duração do tempo limite pode ser definida em CosmosItemRequestOptions. As opções podem ser passadas para qualquer solicitação enviada ao Azure Cosmos DB:

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 você estiver vendo solicitações ficando presas por mais tempo ou expirando com mais frequência, 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. Confira as notas de versão do Java v4 SDK para obter 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%. Utilize 10 segundos como intervalo para monitorizar 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 aumentada vertical ou horizontalmente.

Limitação de conexão

A limitação de conexão pode acontecer devido a um limite de conexão em uma máquina host ou ao esgotamento da porta do Azure SNAT (PAT).

Limite de conexão em uma máquina 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, então esse número limita o número total de conexões também. Execute o seguinte comando.

ulimit -a

Solução:

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

A disponibilidade do socket ou da porta pode ser baixa

Ao executar no Azure, os clientes que usam o Java SDK podem atingir o esgotamento da porta do Azure SNAT (PAT).

Solução 1:

Se você estiver executando em VMs do Azure, siga o guia de exaustão da porta 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). 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 levar a problemas de contenção 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:

Se não for possível ter singleton CosmosClient em um aplicativo, recomendamos usar o compartilhamento de conexão entre vários Clientes do Azure Cosmos DB por meio dessa API connectionSharingAcrossClientsEnabled(true) no CosmosClient. Quando você tem várias instâncias do Cliente do Azure Cosmos DB na mesma JVM interagindo com várias contas do Azure Cosmos DB, habilitar isso permite o compartilhamento de conexão no modo Direto, se possível, entre instâncias do Cliente do Azure Cosmos DB. Observe que, ao definir essa opção, 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 será usada para todas as outras instâncias do cliente.

Chave de partição instantânea

O Azure Cosmos DB distribui o débito aprovisionado global uniformemente entre as partições físicas. Quando existe uma partição instantânea, uma ou mais chaves de partições lógicas numa partição física estão a consumir todas as Unidades de Pedido de partição física por segundo (RU/s). Ao mesmo tempo, serão utilizadas as RU/s noutras partições físicas. Como sintoma, o total de RU/s consumido será menor do que o RU/s provisionado geral no banco de dados ou contêiner, mas você ainda verá limitação (429s) nas solicitações em relação à chave de partição lógica ativa. Use a métrica Consumo de RU normalizado para ver se a carga de trabalho está encontrando 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

O aplicativo está fazendo 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 aumentada vertical ou horizontalmente.

Grandes pedidos ou respostas

Grandes solicitações ou respostas podem levar ao bloqueio do head-of-line no canal e exacerbar a discórdia, mesmo com um grau relativamente baixo de simultaneidade.

Solução:

A aplicação cliente que utiliza o SDK deve ser aumentada vertical ou horizontalmente.

A taxa de falha está dentro do SLA do Azure Cosmos DB

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 repetidas porque em criar caminhos é impossível saber se o serviço criou o item ou não. Enviar o mesmo item novamente para criar causará uma exceção de conflito. A lógica de negócios de aplicativos de usuário pode ter lógica personalizada para lidar com conflitos, o que quebraria a ambiguidade de um item existente versus conflito de uma nova tentativa de criação.

A taxa de falha viola o SLA do Azure Cosmos DB

Entre em contato com o Suporte do Azure.

Próximos passos