Compartilhar via

Diagnosticar e solucionar problemas com exceções de tempo limite de solicitação do SDK do Java v4 do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

O erro HTTP 408 ocorre quando o SDK não consegue completar a solicitação antes de atingir tempo limite.

Etapas para solucionar 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 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 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:

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ê está vendo solicitações ficando presas por mais tempo ou atingindo o tempo limite com mais frequência, atualize o SDK do Java v4 para a última versão. OBSERVAÇÃO: é altamente recomendável usar a versão 4.18.0 e posteriores. Confira as notas sobre a 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 ocorrer devido a um limite de conexão no computador host ou a Esgotamento da porta SNAT (PAT) do Azure.

Limite de conexão no computador host

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

ulimit -a

Solução:

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

A disponibilidade do soquete ou da porta pode estar baixa

Durante a execução no Azure, clientes que usam o SDK do Java podem atingir o esgotamento da porta SNAT do Azure (PAT).

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ê está executando o 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 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ê terá problemas de conexão.

Criar várias instâncias de cliente

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

Solução 1:

Siga as dicas de desempenho e use apenas uma instância de cliente do Cosmos em todo o aplicativo.

Solução 2:

Se não é possível ter um cliente do Cosmos singleton em um aplicativo, recomendamos usar o compartilhamento de conexão entre vários clientes do Azure Cosmos DB por meio da API connectionSharingAcrossClientsEnabled(true) no cliente do Cosmos. 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 de cliente do Azure Cosmos DB. Observe que, ao definir essa opção, a configuração da conexão (por exemplo, configuração de tempo limite do soquete, configuração de tempo limite ocioso) do primeiro cliente instanciado será usada para todas as outras instâncias de cliente.

Chave de partição quente

O Azure Cosmos DB distribui a taxa de transferência provisionada geral de maneira uniforme 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 RUs/s consumidas será menor do que as RUs/s provisionadas no banco de dados ou contêiner, mas você ainda terá limitação (429s) das solicitações em relação à chave de partição lógica quente. Use a Métrica de consumo de RU normalizada para ver 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

Solicitações ou respostas grandes podem levar ao bloqueio de início de linha no canal e exacerbar 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 SLA do Azure Cosmos DB

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 criação causará 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

Entre em contato com o Suporte do Azure.

Próximas etapas