Condividi tramite

Diagnosticare e risolvere i problemi relativi alle eccezioni di timeout della richiesta di Azure Cosmos DB per NoSQL Java v4 SDK

  • Si applica a: ✅ NoSQL

L'errore HTTP 408 si verifica se il software development kit (SDK) non è riuscito a completare la richiesta prima del limite di timeout.

Procedura di risoluzione dei problemi

L'elenco seguente contiene cause note e soluzioni per le eccezioni di timeout delle richieste.

Politica di timeout end-to-end

Esistono scenari in cui si manifestano errori di timeout della rete 408 anche quando vengono implementate tutte le soluzioni preventive. Una procedura consigliata generale per ridurre la latenza della coda e migliorare la disponibilità in questi scenari consiste nell'implementare una politica di timeout end-to-end. La latenza della coda viene ridotta mediante fallimenti più rapidi e le unità di richieste e i costi di calcolo sul lato client vengono ridotti interrompendo i tentativi dopo il timeout. La durata del timeout può essere impostata su CosmosItemRequestOptions. Le opzioni possono quindi essere passate a qualsiasi richiesta inviata ad Azure Cosmos DB per 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);

Problemi esistenti

Se vengono visualizzate richieste bloccate per una durata più lunga o si verifica un timeout più frequente, aggiornare Java v4 SDK alla versione più recente. NOTA: è consigliabile usare la versione 4.18.0 e successive. Consulta le note sulla versione di Java v4 SDK per maggiori dettagli.

Uso elevato della CPU

L'utilizzo elevato della CPU è il caso più comune. Per una latenza ottimale, l'utilizzo della CPU deve essere approssimativamente del 40%. Usare 10 i secondi come intervallo per monitorare l'utilizzo massimo (non medio) della CPU. I picchi di CPU sono più comuni con query tra partizioni in cui potrebbero essere eseguite più connessioni per una singola query.

Soluzione

L'applicazione client che usa l'SDK deve essere ridimensionata o ridotta.

Limitazione delle connessioni

La limitazione delle connessioni può verificarsi a causa di un limite di connessione in un computer host o a un esaurimento delle porte SNAT (Source Network Address Translation) di Azure.

Limite di connessione in un computer host

Alcuni sistemi Linux, ad esempio Red Hat, hanno un limite massimo per il numero totale di file aperti. I socket in Linux vengono implementati come file, quindi questo numero limita anche il numero totale di connessioni. Esegui il comando seguente:

ulimit -a

Soluzione

Il numero massimo di file aperti consentiti, identificati come nofile, deve essere almeno 10.000 o più. Per altre informazioni, vedere i suggerimenti sulle prestazioni di Azure Cosmos DB per NoSQL Java SDK v4.

La disponibilità del socket o della porta potrebbe essere bassa

Quando la soluzione è in esecuzione in Azure, i client che usano Java SDK possono raggiungere l'esaurimento delle porte SNAT di Azure.

Soluzione 1

Se si effettua l'esecuzione su macchine virtuali di Azure, seguire la guida sull'esaurimento delle porte SNAT.

Soluzione 2

Se si utilizza Azure App Service, seguire la guida alla risoluzione degli errori di connessione e utilizzare la diagnostica del Servizio app.

Soluzione 3

Se stai eseguendo Azure Functions, verifica di seguire la raccomandazione di Azure Functions di mantenere i client singleton o statici per tutti i servizi coinvolti (incluso Azure Cosmos DB per NoSQL). Controllare i limiti di servizio in base al tipo e alle dimensioni del proprio hosting dell'app per le funzioni.

Soluzione 4

Se si usa un proxy HTTP, assicurarsi che possa supportare il numero di connessioni configurate in GatewayConnectionConfig dell'SDK. In caso contrario, verranno riscontrati problemi di connessione.

Creare più istanze client

La creazione di più istanze client può causare contese della connessione e problemi di time out.

Soluzione 1

Seguire i suggerimenti sulle prestazioni e usare una singola istanza di CosmosClient in un'intera applicazione.

Soluzione 2

Se singleton CosmosClient non è possibile avere in un'applicazione, è consigliabile usare la condivisione di connessioni tra più client Azure Cosmos DB per NoSQL tramite questa API connectionSharingAcrossClientsEnabled(true) in CosmosClient. Quando sono presenti più istanze del client che interagiscono con più account, l'abilitazione di questa impostazione consente la condivisione della connessione in modalità diretta . Questa modalità è abilitata solo se è possibile condividere connessioni tra istanze del client Azure Cosmos DB per NoSQL. Si noti che, quando si imposta questa opzione di condivisione, la configurazione della connessione (ad esempio, la configurazione del timeout del socket, il timeout di inattività) del primo client istanziato viene usata per tutte le altre istanze client.

Chiave di partizione calda

Azure Cosmos DB per NoSQL distribuisce uniformemente il throughput complessivo fornito tra le partizioni fisiche. Quando è presente una partizione calda, una o più chiavi di partizione logica su una partizione fisica stanno consumando tutte le Unità di Richiesta della partizione fisica per secondo (UR/s). Allo stesso tempo, le RU/s su altre partizioni fisiche non vengono utilizzate. Come sintomo, le UR/sec totali utilizzate sono inferiori alle UR/sec complessive di cui è stato effettuato il provisioning nel database o nel contenitore, ma vengono comunque visualizzate limitazioni (errori 429) sulle richieste rispetto alla chiave di partizione logica ad accesso frequente. Usare la metrica Normalized RU Consumption per verificare se il carico di lavoro incontra una partizione calda.

Soluzione

Scegliere una chiave di partizione valida che distribuisca in modo uniforme il volume e l'archiviazione delle richieste. Leggere come modificare la chiave di partizione.

Livello elevato di concorrenza

L'applicazione sta eseguendo un livello elevato di concorrenza, che può causare contese sul canale.

Soluzione

L'applicazione client che usa l'SDK deve essere ridimensionata o ridotta.

Richieste o risposte di grandi dimensioni

Richieste o risposte di grandi dimensioni possono causare un blocco head-of-line sul canale ed esacerbare la contesa, anche con un grado di concorrenza relativamente basso.

Soluzione

L'applicazione client che usa l'SDK deve essere ridimensionata o ridotta.

La percentuale di errori rientra nel contratto di servizio di Azure Cosmos DB per NoSQL

L'applicazione deve essere in grado di gestire gli errori temporanei e riprovare quando necessario. Eventuali eccezioni 408 non vengono ritentate perché nei percorsi di creazione non è possibile sapere se il servizio ha creato o meno l'elemento. L'invio dello stesso elemento per la creazione causa un'eccezione di conflitto. La logica di business delle applicazioni utente potrebbe avere una logica personalizzata per gestire i conflitti, che potrebbe interrompere l'ambiguità di un elemento esistente rispetto al conflitto dovuto a un nuovo tentativo di creazione.

La frequenza di errore viola il contratto di servizio di Azure Cosmos DB per NoSQL

Contattare il supporto di Azure.

Contenuti correlati

  • Last updated on