Dela via

Diagnostisera och felsöka tidsgränsundantag för Azure Cosmos DB .NET 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.

Det är viktigt att se till att programdesignen följer vår guide för att utforma motståndskraftiga program med Azure Cosmos DB SDK:er för att se till att den reagerar korrekt på olika nätverksförhållanden. Programmet bör ha återförsök för timeout-fel eftersom dessa normalt är förväntade i ett distribuerat system.

När du utvärderar ärendet för timeout-fel:

  • Hur är påverkan mätt i volymen av åtgärder jämfört med de åtgärder som lyckas? Finns det i serviceavtalen?
  • Påverkas P99-svarstiden/tillgängligheten?
  • Påverkar felen alla programinstanser eller bara en delmängd? När problemet reduceras till en delmängd av instanser är det ofta ett problem som är relaterat till dessa instanser.

Ändra tidsgränsen i Azure Cosmos DB .NET SDK

SDK:et har två olika alternativ för att kontrollera tidsgränser, var och en med olika omfång.

Tidsgränser för begärandenivå

Med konfigurationen CosmosClientOptions.RequestTimeout (eller ConnectionPolicy.RequestTimeout för SDK v2) kan du ange en tidsgräns för nätverksbegäran efter att begäran lämnade SDK:n och finns i nätverket tills ett svar tas emot.

Med konfigurationen CosmosClientOptions.OpenTcpConnectionTimeout (eller ConnectionPolicy.OpenTcpConnectionTimeout för SDK v2) kan du ange en tidsgräns för den tid som ägnas åt att öppna en inledande anslutning. När en anslutning har öppnats använder efterföljande begäranden anslutningen.

En åtgärd som startas av en användare kan omfatta flera nätverksbegäranden, till exempel återförsök. Dessa två konfigurationer är per begäran, inte från slutpunkt till slutpunkt för en åtgärd.

CancellationToken

Alla asynkrona åtgärder i SDK har en valfri CancellationToken-parameter. Parametern CancellationToken används under hela åtgärden, för alla nätverksbegäranden och återförsök. Annulleringstoken kan kontrolleras mellan nätverksbegäranden, och en åtgärd avbryts om den relaterade token har upphört att gälla. Annulleringstoken ska användas för att definiera en ungefärlig förväntad tidsgräns för åtgärdsomfånget.

Kommentar

Parametern CancellationToken är en mekanism där biblioteket kontrollerar annulleringen när den inte orsakar ett ogiltigt tillstånd. Åtgärden kanske inte avbryts exakt den tid som definierats för annulleringen. När tiden har gått ut sker annulleringen i stället när det är säkert att utföra den.

Felsökningsanvisningar

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

CosmosOperationCanceledException

Den här typen av undantag är vanliga när programmet skickar CancellationTokens till SDK-åtgärderna. SDK:et kontrollerar tillståndet för mellanförsöken CancellationToken och om den CancellationToken avbryts avbryts den aktuella åtgärden med det här undantaget.

Message / ToString() Undantaget anger också tillståndet för din CancellationToken genom Cancellation Token has expired: true och innehåller även diagnostik som innehåller kontexten för annulleringen för de berörda begärandena.

Dessa undantag är säkra att försöka igen på och kan behandlas som tidsgränser från återförsöksperspektivet.

Lösning

Kontrollera den konfigurerade tiden i , CancellationTokenkontrollera att den är större än din RequestTimeout och CosmosClientOptions.OpenTcpConnectionTimeout (om du använder direktläge). Om den tillgängliga tiden i CancellationToken är mindre än de konfigurerade tidsgränserna och SDK:t har tillfälliga anslutningsproblem kommer SDK:t inte att kunna försöka igen och genererar CosmosOperationCanceledException.

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.

Tidsgränserna innehåller diagnostik som innehåller:

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • cpu Om värdena är över 70 %, orsakas tidsgränsen troligen av CPU-överbelastning. I det här fallet är lösningen att undersöka källan till hög processoranvändning och minska den, eller skala datorn till en större resursstorlek.
  • threadInfo/isThreadStarving Om noderna har True värden är orsaken trådsvältning. I det här fallet är lösningen att undersöka orsaken till trådsvälten (potentiellt låsta trådar) eller skala datorn/datorerna till en större resursstorlek.
  • dateUtc Om tiden mellan mätningarna inte är cirka 10 sekunder skulle det också indikera konkurrens i trådpoolen. CPU mäts som en oberoende aktivitet som sätts i kö i trådpoolen var 10:e sekund, om tiden mellan mätningen är längre, tyder det på att asynkrona aktiviteter inte kan bearbetas inom rimlig tid. De vanligaste scenarierna är vid anropsblockering via asynkron kod i programkoden.

Lösning

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

Socket- eller porttillgängligheten kan vara låg

När du kör i Azure kan klienter som använder .NET 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 ConnectionPolicy. Annars kommer du att stöta på anslutningsproblem.

Skapa flera klientinstanser

Att skapa flera klientinstanser kan leda till problem med anslutningskonkurration och tidsgränser. Diagnostiken innehåller två relevanta egenskaper:

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated spårar antalet gånger som en CosmosClient skapades inom samma AppDomain och NumberOfActiveClients spårar de aktiva klienterna (tas inte bort). Förväntningen är att om singleton-mönstret följs skulle X det matcha antalet konton som programmet fungerar med och som X är lika Ymed .

Om X är större än Yinnebär det att programmet skapar och tar bort klientinstanser. Detta kan leda till anslutningskonkurration och/eller CPU-konkurrens.

Lösning

Följ prestandatipsen och använd en enda CosmosClient-instans per konto i en hel process. Undvik att skapa och disponera klienter.

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