Dela via

Diagnostisera och felsöka timeout-undantag för Azure Cosmos DB Java v4 SDK-begäran

  • Artikel

GÄLLER FÖR: NoSQL

HTTP-fel 408 uppstår om SDK inte kunde slutföra begäran innan tidsgränsen nåddes.

Felsökningsanvisningar

Följande lista innehåller kända orsaker och lösningar för tidsgränsundantag vid begäranden.

Tidsgränsprincip från slutpunkt till slutpunkt

Det finns scenarier där tidsgränsfel för 408 nätverk inträffar även när alla förebyggande lösningar som nämns nedan har implementerats. En allmän metod för att minska svarstiden för svansen och förbättra tillgängligheten i dessa scenarier är att implementera en tidsgränsprincip från slutpunkt till slutpunkt. Svarstiden minskas genom snabbare fel, och enheter för begäranden och beräkningskostnader på klientsidan minskas genom att återförsök stoppas efter tidsgränsen. Tidsgränsen kan ställas in på CosmosItemRequestOptions. Alternativen kan sedan skickas till alla begäranden som skickas till 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);

Befintliga problem

Om du ser förfrågningar som fastnar under längre tid eller tar längre tid, uppgraderar du Java v4 SDK till den senaste versionen. Obs! Vi rekommenderar starkt att du använder version 4.18.0 och senare. Kolla in viktig information om Java v4 SDK för mer information.

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 den maximala (inte genomsnittliga) processoranvändningen. CPU-användningstoppar är vanligare för frågor mellan partitioner där det kan göras flera anslutningar för en enskild fråga.

Lösning:

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

Anslutningsbegränsning

Anslutningsbegränsning kan inträffa på grund av antingen en anslutningsgräns på en värddator eller på grund av överbelastning av Azure SNAT-portar (PAT).

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 Java SDK v4.

Socket- eller porttillgängligheten kan vara låg

När du kör i Azure kan klienter som använder Java SDK drabbas av överbelastning av Azure SNAT-portar (PAT).

Lösning 1:

Om du kör på virtuella Azure-datorer följer du SNAT-portöverbelastningsguiden.

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). 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 kommer du att stöta på anslutningsproblem.

Skapa flera klientinstanser

Att skapa flera klientinstanser kan leda till problem med anslutningskonkurration och tidsgränser.

Lösning 1:

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

Lösning 2:

Om det inte går att använda singleton CosmosClient i ett program rekommenderar vi att du använder anslutningsdelning mellan flera Azure Cosmos DB-klienter via det här API: connectionSharingAcrossClientsEnabled(true) et i CosmosClient. När du har flera instanser av Azure Cosmos DB-klienten i samma JVM som interagerar med flera Azure Cosmos DB-konton, möjliggör aktivering av detta anslutningsdelning i direktläge om möjligt mellan instanser av Azure Cosmos DB-klienten. Observera att när du anger det här alternativet används anslutningskonfigurationen (t.ex. timeoutkonfiguration för socket, timeout-konfiguration för inaktiv) för den första instansierade klienten för alla andra klientinstanser.

Nyckel för frekvent partition

Azure Cosmos DB fördelar det övergripande etablerade dataflödet jämnt över fysiska partitioner. När det finns en frekvent partition förbrukar en eller flera logiska partitionsnycklar på en fysisk partition den fysiska partitionens samtliga enheter för programbegäran per sekund (RU/s). Samtidigt används inte RU/s på andra fysiska partitioner. Som ett symptom är den totala förbrukade RU/s mindre än den totala etablerade RU/s i databasen eller containern, men du ser fortfarande begränsning (429:or) 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 frekvent 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 samtidighetsnivå, vilket kan leda till konkurrens på 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 SLA

Programmet ska kunna hantera tillfälliga fel och försöka igen vid behov. Eventuella 408 undantag görs inte igen eftersom det vid skapa sökvägar är omöjligt att veta om tjänsten skapade objektet eller inte. Att skicka samma objekt igen för att skapa orsakar ett konfliktfel. Affärslogik för användarprogram kan ha anpassad logik för att hantera konflikter, vilket skulle bryta mot tvetydigheten i ett befintligt objekt jämfört med konflikt från ett nytt försök att skapa.

Felfrekvensen bryter mot serviceavtalet för Azure Cosmos DB

Kontakta Azure Support.

Nästa steg