Dela via

Diagnostisera och åtgärda undantag vid tidsöverträdelser för begäran i Azure Cosmos DB för NoSQL .NET SDK

  • Gäller för: ✅ NoSQL

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

Det är viktigt att se till att programdesignen följer vår guide för att utforma motståndskraftiga program med Azure Cosmos DB för NoSQL SDK för att se till att den reagerar korrekt på olika nätverksförhållanden. Ditt program bör ha mekanismer för att göra nya försök vid timeout-fel eftersom dessa fel normalt förväntas i ett distribuerat system.

När du utvärderar ärendet för timeout-fel bör du överväga följande åtgärder:

  • Mät effekten i volymen av åtgärder som påverkas jämfört med de åtgärder som lyckas.
  • Avgör om effekten ligger inom de tröskelvärden som definierats i servicenivåavtalet.
  • Utvärdera hur P99-svarstiden eller tillgängligheten påverkas.
  • Identifiera om felet påverkar alla programinstanser eller endast en delmängd.

Anpassa tidsgränsen för Azure Cosmos DB för NoSQL .NET SDK

SDK:et har två distinkta alternativ för att hantera timeout, var och en med ett annat omfång.

Tidsgräns för begärandenivå

Med konfigurationen ConnectionPolicy.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 ConnectionPolicy.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 förfrågan, inte end-to-end för en operation.

Avbrytningstoken (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.

Anmärkning

Parametern CancellationToken är en mekanism där biblioteket kontrollerar om annulleringen kan orsaka 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ökningssteg

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

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 CancellationToken mellan försöken och om 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 Diagnostics som ger kontexten för annulleringen av de berörda begärandena.

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

Lösning

Kontrollera den konfigurerade tiden i CancellationToken. Kontrollera sedan att det är större än begäran tidsgräns och egenskapen CosmosClientOptions.OpenTcpConnectionTimeout (om du använder direktläge). Om den tillgängliga tiden i CancellationToken är mindre än den konfigurerade tidsgränsen och SDK:t har tillfälliga anslutningsproblem kan SDK:t inte försöka igen och utlöser ett CosmosOperationCanceledException undantag.

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.

Tidsgränsen, som innehåller Diagnostics, inkluderar:

"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 CPU-värdena är över 70 procent orsakade CPU-överbelastning sannolikt en timeout. I det här fallet är lösningen att undersöka källan till den höga CPU-användningen och minska den, eller uppgradera datorn till en kraftfullare resurs.
  • threadInfo/isThreadStarving Om noderna har True värden är orsaken trådsvältning. I det här fallet är lösningen att undersöka källan/s för trådsvältningen (potentiellt låsta trådar) eller skala datorn/datorerna till en större resursstorlek.
  • dateUtc Om tiden mellan mätningarna inte är ungefär 10 sekunder skulle det också indikera konkurrens i trådpoolen. CPU mäts som en oberoende uppgift som placeras i trådpoolen varje 10 sekund. Om tiden mellan mätningarna är längre skulle det tyda på att asynkrona uppgifter inte kan bearbetas i tid. Det här scenariot inträffar ofta när du utför blockeringsanrop över 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 din lösning körs i Azure kan klienter som använder .NET SDK uppleva brist på SNAT-portar (Azure Source Network Address Translation).

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 ConnectionPolicy. Annars kan du stöta på anslutningsproblem.

Skapa flera klientinstanser

Att skapa flera klientinstanser kan leda till anslutningskonflikter och tidsgränsproblem. 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 så skulle X matcha antalet konton som applikationen arbetar med och att X är lika med Y.

Om X är större än Yinnebär det att programmet skapar och tar bort klientinstanser. Det här scenariot 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 kassera klienter.

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 etablerade RU/s i databasen eller containern, men begränsning (429 fel) på begäranden för den heta logiska partitionsnyckeln sker. Använd måttetNormalized RU Consumption för att se om arbetsbelastningen stöter på 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 för create orsakar ett konfliktfel. 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