Felsöka tillgänglighetsproblem i Azure Storage-konton

  • Artikel

Den här artikeln hjälper dig att undersöka ändringar i tillgängligheten (till exempel antalet misslyckade begäranden). Dessa ändringar i tillgängligheten kan ofta identifieras genom övervakning av lagringsmått i Azure Monitor. Allmän information om hur du använder mått och loggar i Azure Monitor finns i följande artiklar:

Övervaka tillgänglighet

Du bör övervaka tillgängligheten för lagringstjänsterna i ditt lagringskonto genom att övervaka värdet för måttet Tillgänglighet . Måttet Tillgänglighet innehåller ett procentvärde. Det beräknas genom att det totala värdet för fakturerbara begäranden divideras med antalet tillämpliga begäranden, inklusive de begäranden som gav oväntade fel.

Ett värde som är mindre än 100 % anger att vissa lagringsbegäranden misslyckas. Du kan se varför de misslyckas genom att undersöka ResponseType-dimensionen för feltyper som ServerTimeoutError. Du bör förvänta dig att tillgängligheten tillfälligt understiger 100 % av orsaker som tillfälliga tidsgränser för servern medan tjänsten flyttar partitioner till bättre belastningsutjämningsbegäranden. omprövningslogik i klientprogrammet ska hantera sådana tillfälliga villkor.

Du kan använda funktioner i Azure Monitor för att varna dig om tillgängligheten för en tjänst understiger ett tröskelvärde som du anger.

Mått visar en ökning av begränsningsfel

Begränsningsfel uppstår när du överskrider skalbarhetsmålen för en lagringstjänst. Lagringstjänsten begränsar för att säkerställa att ingen enskild klient eller klient kan använda tjänsten på bekostnad av andra. Mer information finns i Skalbarhets- och prestandamål för standardlagringskonton för information om skalbarhetsmål för lagringskonton och prestandamål för partitioner i lagringskonton.

Om värdet ClientThrottlingError eller ServerBusyError för dimensionen ResponseType visar en ökning av procentandelen begäranden som misslyckas med ett begränsningsfel, måste du undersöka något av två scenarier:

  • Tillfällig ökning i PercentThrottlingError
  • Permanent ökning av PercentThrottlingError-fel

En ökning av begränsningsfel sker ofta samtidigt som antalet lagringsbegäranden ökar eller när du först läser in programmet. Detta kan också visa sig i klienten som "503 Servern är upptagen" eller "500 åtgärd timeout" HTTP-statusmeddelanden från lagringsåtgärder.

Tillfällig ökning av begränsningsfel

Om du ser toppar i begränsningsfel som sammanfaller med perioder med hög aktivitet för programmet implementerar du en exponentiell (inte linjär) backoff-strategi för återförsök i klienten. Backoff-återförsök minskar den omedelbara belastningen på partitionen och hjälper ditt program att jämna ut trafiktopparna. Mer information om hur du implementerar återförsöksprinciper med hjälp av storage-klientbiblioteket finns i egenskapen RetryOptions.MaxRetries .

Obs!

Du kan också se toppar i begränsningsfel som inte sammanfaller med perioder med hög aktivitet för programmet. Den troligaste orsaken är att lagringstjänsten flyttar partitioner för att förbättra belastningsutjämningen.

Permanent ökning av begränsningsfel

Om du ser ett konsekvent högt värde för begränsningsfel efter en permanent ökning av dina transaktionsvolymer eller när du utför dina första belastningstester för ditt program, måste du utvärdera hur ditt program använder lagringspartitioner och om det närmar sig skalbarhetsmålen för ett lagringskonto. Om du till exempel ser begränsningsfel i en kö (som räknas som en enda partition) kan du överväga att använda ytterligare köer för att sprida transaktionerna över flera partitioner. Om du ser begränsningsfel i en tabell bör du överväga att använda ett annat partitioneringsschema för att sprida dina transaktioner över flera partitioner med hjälp av ett bredare intervall med partitionsnyckelvärden. En vanlig orsak till det här problemet är antimönstret prepend/append, där du väljer datumet som partitionsnyckel och sedan skrivs alla data på en viss dag till en partition (under belastning kan detta resultera i en flaskhals för skrivning). Överväg en annan partitioneringsdesign eller utvärdera om användning av bloblagring kan vara en bättre lösning. Kontrollera också om begränsningen sker på grund av toppar i trafiken och undersöka olika sätt att jämna ut mönstret för begäranden.

Om du distribuerar dina transaktioner över flera partitioner måste du fortfarande vara medveten om de skalbarhetsgränser som angetts för lagringskontot. Om du till exempel använde 10 köer, där var och en bearbetar högst 2 000 1 KB-meddelanden per sekund, kommer du att ha den övergripande gränsen på 20 000 meddelanden per sekund för lagringskontot. Om du behöver bearbeta fler än 20 000 entiteter per sekund bör du överväga att använda flera lagringskonton. Tänk också på att storleken på dina begäranden och entiteter påverkar när lagringstjänsten begränsar dina klienter. Om du har större begäranden och entiteter kan du begränsas tidigare.

Ineffektiv frågedesign kan också göra att du når skalbarhetsgränserna för tabellpartitioner. Till exempel måste en fråga med ett filter som bara väljer en procent av entiteterna i en partition, men som söker igenom alla entiteter i en partition komma åt varje entitet. Varje entitetsläsning räknas mot det totala antalet transaktioner i partitionen. Därför kan du enkelt nå skalbarhetsmålen.

Obs!

Prestandatestningen bör visa ineffektiva frågedesigner i ditt program.

Mått visar en ökning av timeout-fel

Timeout-fel uppstår när ResponseType-dimensionen är lika med ServerTimeoutError eller ClientTimeout.

Dina mått visar en ökning av tidsgränsfel för någon av dina lagringstjänster. Samtidigt tar klienten emot en stor mängd HTTP-statusmeddelanden för "500 åtgärdstimeout" från lagringsåtgärder.

Obs!

Du kan tillfälligt se timeout-fel när lagringstjänsten lastbalanserar begäranden genom att flytta en partition till en ny server.

Serverns timeouter (ServerTimeOutError) orsakas av ett fel på servern. Tidsgränsen för klienten (ClientTimeout) inträffar eftersom en åtgärd på servern har överskridit den tidsgräns som anges av klienten. En klient som använder storage-klientbiblioteket kan till exempel ange en tidsgräns för en åtgärd.

Tidsgränser för servern indikerar ett problem med lagringstjänsten som kräver ytterligare undersökning. Du kan använda mått för att se om du når skalbarhetsgränserna för tjänsten och för att identifiera eventuella trafiktoppar som kan orsaka det här problemet. Om problemet är tillfälligt kan det bero på belastningsutjämningsaktivitet i tjänsten. Om problemet är beständigt och inte orsakas av att programmet når tjänstens skalbarhetsgränser bör du skapa ett supportproblem. För klienttimeouter måste du bestämma om tidsgränsen är inställd på ett lämpligt värde i klienten och antingen ändra tidsgränsvärdet som angetts i klienten eller undersöka hur du kan förbättra prestandan för åtgärderna i lagringstjänsten, till exempel genom att optimera dina tabellfrågor eller minska storleken på dina meddelanden.

Mått visar en ökning av nätverksfel

Nätverksfel uppstår när ResponseType-dimensionen är lika med NetworkError. Dessa inträffar när en lagringstjänst identifierar ett nätverksfel när klienten gör en lagringsbegäran.

Den vanligaste orsaken till det här felet är att en klient kopplar från innan en tidsgräns går ut i lagringstjänsten. Undersök koden i klienten för att förstå varför och när klienten kopplas från lagringstjänsten. Du kan också använda verktyg för nätverksanalys från tredje part för att undersöka problem med nätverksanslutningen från klienten.

Se även

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.