Condividi tramite

Diagnosticare e risolvere le eccezioni di timeout delle richieste di Azure Cosmos DB Java v4 SDK

  • Articolo

SI APPLICA A: NoSQL

L'errore HTTP 408 si verifica se l'SDK non è stato in grado di completare la richiesta prima del raggiungimento del limite di timeout.

Passaggi per la risoluzione dei problemi

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

Criteri di timeout end-to-end

Esistono scenari in cui si verificheranno errori di timeout di rete 408 anche quando sono state implementate tutte le soluzioni preliminari indicate di seguito. Una procedura consigliata generale per ridurre la latenza della coda e migliorare la disponibilità in questi scenari consiste nell'implementare criteri di timeout end-to-end. La latenza della coda viene ridotta fallendo e rispondendo immediatamente agli errori, mentre le unità richiesta e i costi di calcolo lato client vengono ridotti arrestando 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:

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 si nota che le richieste rimangono bloccate per una durata più lunga o si verifica un timeout più frequente, aggiornare l'SDK Java v4 alla versione più recente. NOTA: è consigliabile usare la versione 4.18.0 e versioni successive. Per maggiori dettagli, consultare le note di rilascio dell'SDK Java v4.

Utilizzo 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 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 della connessione

La limitazione delle connessioni può verificarsi a causa di un limite di connessioni nel computer host o di un esaurimento delle porte SNAT (PAT) di Azure.

Limite di connessioni nel computer host

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

ulimit -a

Soluzione:

Il numero massimo consentito di file aperti, identificati come "nofile", deve essere almeno 10.000. Per altre informazioni, vedere i suggerimenti per le prestazioni relativi ad Azure Cosmos DB Java SDK v4.

La disponibilità del socket o della porta potrebbe essere bassa

Durante l'esecuzione in Azure, i client che utilizzano l'SDK Java possono raggiungere l'esaurimento della porta SNAT (PAT) di Azure.

Soluzione n. 1:

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

Soluzione n. 2:

Se si effettua l'esecuzione sul Servizio app di Azure, seguire la guida alla risoluzione degli errori di connessione e usare la diagnostica del servizio app.

Soluzione n. 3:

Se si effettua l'esecuzione su Funzioni di Azure, verificare di seguire la raccomandazione di Funzioni di Azure di mantenere client singleton o statici per tutti i servizi coinvolti (incluso Azure Cosmos DB). Controllare i limiti di servizio in base al tipo e alle dimensioni del proprio hosting dell'app per le funzioni.

Soluzione n. 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 conflitti di connessione e problemi di timeout.

Soluzione n. 1:

Seguire i suggerimenti sulle prestazionie usare una singola istanza CosmosClient in un'intera applicazione.

Soluzione n. 2:

Se non è possibile avere CosmosClient singleton in un'applicazione, è consigliabile usare la condivisione di connessioni tra più client Azure Cosmos DB tramite questa API connectionSharingAcrossClientsEnabled(true) in CosmosClient. Quando si dispone di più istanze del client Azure Cosmos DB nella stessa JVM che interagiscono con più account Azure Cosmos DB, abilitare questa per consentire la condivisione della connessione in modalità diretta, se possibile tra istanze del client Azure Cosmos DB. Si noti che, quando si imposta questa opzione, la configurazione della connessione (ad esempio la configurazione del timeout del socket e la configurazione del timeout di inattività) del primo client di cui è stata creata un'istanza verrà usata per tutte le altre istanze client.

Chiavi di partizione ad accesso frequente

Azure Cosmos DB distribuisce in modo uniforme la velocità effettiva complessiva con provisioning tra partizioni fisiche. Quando è presente una partizione ad accesso frequente, una o più chiavi di partizione logica in una partizione fisica usano tutte le unità richiesta della partizione fisica al secondo (UR/s). Allo stesso tempo, le UR/s in altre partizioni fisiche non verranno utilizzate. Come sintomo, le UR/sec totali consumate saranno inferiori alle UR/sec complessive di cui è stato effettuato il provisioning nel database o nel contenitore, ma si noterà comunque una limitazione (429s) sulle richieste rispetto alla chiave di partizione logica ad accesso frequente. Usare la metrica Normalized UR Consumption per verificare se il carico di lavoro stia riscontrando una partizione ad accesso frequente.

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, cosa che può portare a 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.

Il tasso di errore rientra nel contratto di servizio di Azure Cosmos DB

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 causerà 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.

Il tasso di errore viola il contratto di servizio di Azure Cosmos DB

Contattare il supporto di Azure.

Passaggi successivi