Diagnostisera och felsöka timeout-undantag av begäran i Azure Cosmos DB NoSQL Java v4 SDK.

HTTP 408-felet inträffar om programvaruutvecklingspaketet (SDK) inte kunde slutföra begäran innan tidsgränsen inträffade.

Felsökningssteg

Följande lista innehåller kända orsaker och lösningar för timeout-undantag för begäran.

Tidsgränspolicy från början till slut

Det finns situationer där 408-nätverkets timeout-fel inträffar även när alla förebyggande lösningar har implementerats här. En allmän metod för att minska svarstiden och förbättra tillgängligheten i dessa scenarier är att implementera en tidsgränsprincip från slutpunkt till slutpunkt. Svarstiden minskas genom att fel identifieras snabbare och begärandenheter samt beräkningskostnader på klientsidan minskas genom att återförsök stoppas när tidsfristen löper ut. Tidsgränsen kan ställas in på CosmosItemRequestOptions. Alternativen kan sedan skickas till alla begäranden som skickas till Azure Cosmos DB för 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);

Befintliga problem

Om du märker att förfrågningar fastnar under längre perioder eller leder till timeout oftare, bör du uppgradera Java v4 SDK till den senaste versionen. Obs! Vi rekommenderar starkt att du använder version 4.18.0 och senare. Mer information finns i viktig information om Java v4 SDK .

Hög CPU-belastning

Hög processoranvändning är det vanligaste fallet. För att få en optimal svarstid bör processoranvändningen vara ungefär 40 procent. Använd 10 sekunder som intervall för att övervaka maximal (inte genomsnittlig) CPU-användning. CPU-användningstoppar är vanligare vid frågor som går över partitioner, där flera anslutningar kan göras för en enskild fråga.

Lösning

Klientprogrammet som använder SDK:t ska skalas upp eller ut.

Anslutningsstrypning

Anslutningsbegränsning kan inträffa på grund av antingen en anslutningsgräns på en värddator eller brist på SNAT-portar (Azure Source Network Address Translation).

Anslutningsgräns på en värddator

Vissa Linux-system, till exempel Red Hat, har en övre gräns för det totala antalet öppna filer. Sockets i Linux implementeras som filer, så det här antalet begränsar även det totala antalet anslutningar. Kör följande kommando.

ulimit -a

Lösning

Antalet maximalt tillåtna öppna filer, som identifieras som nofile, måste vara minst 10 000 eller mer. Mer information finns i Prestandatips för Azure Cosmos DB for NoSQL Java SDK v4.

Socket- eller porttillgängligheten kan vara låg

När din lösning körs i Azure kan klienter som använder Java SDK drabbas av överbelastning av Azure SNAT-portar.

Lösning 1

Om du kör på Azure-virtuella datorer, följ guiden för SNAT-portöverbelastning.

Lösning 2

Om du kör i Azure App Service följer du felsökningsguiden för anslutningsfel och använder App Service-diagnostik.

Lösning 3

Om du kör azure functions kontrollerar du att du följer Azure Functions-rekommendationen att underhålla singleton- eller statiska klienter för alla berörda tjänster (inklusive Azure Cosmos DB för NoSQL). Kontrollera tjänstbegränsningarna baserat på typen och storleken på funktionsappens värd.

Lösning 4

Om du använder en HTTP-proxy kontrollerar du att den har stöd för antalet anslutningar som konfigurerats i SDK GatewayConnectionConfig. Annars kan du stöta på anslutningsproblem.

Skapa flera klientinstanser

Att skapa flera klientinstanser kan leda till anslutningskonflikter och tidsgränsproblem.

Lösning 1

Följ prestandatipsen och använd en enda CosmosClient-instans i ett helt program.

Lösning 2

Om singleton CosmosClient inte går att ha i ett program rekommenderar vi att du använder anslutningsdelning över flera Azure Cosmos DB för NoSQL-klienter via det här API: connectionSharingAcrossClientsEnabled(true) et i CosmosClient. Om du har flera instanser av klienten som interagerar med flera konton, tillåter aktivering av den här inställningen anslutningsdelning i direktläge . Det här läget är endast aktiverat om anslutningsdelning är möjligt mellan instanser av Azure Cosmos DB för NoSQL-klienten. Observera att när du anger det här delningsalternativet används anslutningskonfigurationen (t.ex. tidsgräns för socketkonfiguration, tidsgräns för inaktivitet) för den första instansierade klienten för alla andra klientinstanser.

Het partitionsnyckel

Azure Cosmos DB for NoSQL distribuerar det övergripande etablerade dataflödet jämnt över fysiska partitioner. När det finns en het partition förbrukar en eller flera logiska partitionsnycklar alla begäransenheter per sekund (RU/s) som finns tillgängliga på en fysisk partition. Samtidigt används inte RU/s på de andra fysiska partitionerna. Som ett symptom är den totala RU/s som förbrukas mindre än den totala tillhandahållna RU/s i databasen eller containern, men du ser fortfarande strypning (429 fel) på begäranden mot den frekventa logiska partitionsnyckeln. Använd måttet Normaliserad RU-förbrukning för att se om arbetsbelastningen påträffar en het partition.

Lösning

Välj en bra partitionsnyckel som jämnt distribuerar begärandevolym och lagring. Lär dig hur du ändrar partitionsnyckeln.

Hög grad av samtidighet

Programmet utför en hög grad av samtidighet, vilket kan leda till tävlan om kanalen.

Lösning

Klientprogrammet som använder SDK:t ska skalas upp eller ut.

Stora begäranden eller svar

Stora begäranden eller svar kan leda till blockering på kanalen och förvärra konkurrensen, även med en relativt låg grad av samtidighet.

Lösning

Klientprogrammet som använder SDK:t ska skalas upp eller ut.

Felfrekvensen ligger inom Azure Cosmos DB för NoSQL-serviceavtal (SLA)

Programmet ska kunna hantera tillfälliga fel och försöka igen vid behov. Eventuella 408-fel förs inte igen eftersom det vid skapandet av sökvägar är omöjligt att veta om tjänsten har skapat objektet eller inte. Att skicka samma objekt igen vid skapande orsakar ett konfliktundantag. Affärslogik för användarprogram kan ha anpassad logik för att hantera konflikter, vilket skulle avlägsna tvetydigheten hos ett befintligt objekt jämfört med en konflikt som uppstår vid ett nytt skapelseförsök.

Felfrekvensen bryter mot Azure Cosmos DB för NoSQL SLA

Kontakta Azure Support.

Relaterat innehåll

• Diagnostisera och felsöka problem när du använder Azure Cosmos DB för NoSQL Java v4 SDK.
• Läs mer om prestandariktlinjer för Java v4.