Felsöka prestanda i Azure Storage-konton

Artikel
04/10/2024

Den här artikeln hjälper dig att undersöka oväntade förändringar i beteendet (till exempel långsammare svarstider än vanligt). Dessa ändringar i beteendet 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 prestanda

Om du vill övervaka lagringstjänsternas prestanda kan du använda följande mått:

Måtten SuccessE2ELatency och SuccessServerLatency visar den genomsnittliga tid som lagringstjänsten eller API-åtgärdstypen tar för att bearbeta begäranden. SuccessE2ELatency är ett mått på svarstid från slutpunkt till slutpunkt som inkluderar den tid det tar att läsa begäran och skicka svaret utöver den tid det tar att bearbeta begäran (därför inkluderar den nätverksfördröjning när begäran når lagringstjänsten). SuccessServerLatency är ett mått på bara bearbetningstiden och utesluter därför alla nätverksfördröjningar som är relaterade till kommunikation med klienten.
Måtten Egress och Ingress visar den totala mängden data, i byte, som kommer in till och går ut från din lagringstjänst eller via en specifik API-åtgärdstyp.
Måttet Transaktioner visar det totala antalet begäranden som lagringstjänsten för API-åtgärden tar emot. Transaktioner är det totala antalet begäranden som lagringstjänsten tar emot.

Du kan övervaka oväntade ändringar i något av dessa värden. Dessa ändringar kan tyda på ett problem som kräver ytterligare undersökning.

I Azure Portal kan du lägga till aviseringsregler som meddelar dig när något av prestandamåtten för den här tjänsten faller under eller överskrider ett tröskelvärde som du anger.

Diagnostisera prestandaproblem

Prestandan för ett program kan vara subjektiv, särskilt ur ett användarperspektiv. Därför är det viktigt att ha baslinjemått tillgängliga för att hjälpa dig att identifiera var det kan finnas ett prestandaproblem. Många faktorer kan påverka prestandan för en Azure Storage-tjänst ur klientprogramperspektivet. Dessa faktorer kan fungera i lagringstjänsten, klienten eller nätverksinfrastrukturen. Därför är det viktigt att ha en strategi för att identifiera ursprunget till prestandaproblemet.

När du har identifierat den troliga platsen för orsaken till prestandaproblemet från måtten kan du sedan använda loggfilerna för att hitta detaljerad information för att diagnostisera och felsöka problemet ytterligare.

Mått visar hög SuccessE2ELatency och låg SuccessServerLatency

I vissa fall kan du upptäcka att SuccessE2ELatency är högre än SuccessServerLatency. Lagringstjänsten beräknar endast måttet SuccessE2ELatency för lyckade begäranden och inkluderar, till skillnad från SuccessServerLatency, den tid klienten tar att skicka data och ta emot bekräftelse från lagringstjänsten. Därför kan en skillnad mellan SuccessE2ELatency och SuccessServerLatency bero på att klientprogrammet svarar långsamt eller på grund av nätverksförhållanden.

Obs!

Du kan också visa E2ELatency och ServerLatency för enskilda lagringsåtgärder i loggdata för lagringsloggning.

Undersöka problem med klientprestanda

Möjliga orsaker till att klienten svarar långsamt är att ha begränsade tillgängliga anslutningar eller trådar eller att det är ont om resurser som PROCESSOR, minne eller nätverksbandbredd. Du kanske kan lösa problemet genom att ändra klientkoden så att den blir effektivare (till exempel genom att använda asynkrona anrop till lagringstjänsten) eller genom att använda en större virtuell dator med fler kärnor och mer minne.

För tabell- och kötjänsterna kan Nagle-algoritmen också orsaka hög SuccessE2ELatency jämfört med SuccessServerLatency. Mer information finns i inlägget nagles algoritm är inte vänlig mot små begäranden. Du kan inaktivera Nagle-algoritmen i kod med hjälp ServicePointManager av klassen i System.Net namnområdet. Du bör göra detta innan du gör några anrop till tabellen eller kötjänsterna i ditt program eftersom detta inte påverkar anslutningar som redan är öppna. Följande exempel kommer från Application_Start metoden i en arbetsroll:

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Du bör kontrollera loggarna på klientsidan för att se hur många begäranden som klientprogrammet skickar och söka efter allmänna .NET-relaterade prestandaflaskhalsar i klienten, till exempel CPU, .NET-skräpinsamling, nätverksanvändning eller minne. Som utgångspunkt för felsökning av .NET-klientprogram kan du läsa Felsökning, Spårning och Profilering.

Undersöka problem med nätverksfördröjning

Normalt beror långa svarstider från slutpunkt till slutpunkt som orsakas av nätverket på tillfälliga förhållanden. Du kan undersöka både tillfälliga och beständiga nätverksproblem, till exempel borttagna paket, med hjälp av verktyg som Wireshark.

Mått visar låg SuccessE2ELatency och låg SuccessServerLatency men klienten har hög svarstid

I det här scenariot är den troligaste orsaken en fördröjning i lagringsbegäran som når lagringstjänsten. Du bör undersöka varför begäranden från klienten inte skickas till blobtjänsten.

En möjlig orsak till att klienten fördröjer sändningen av begäranden är att det finns ett begränsat antal tillgängliga anslutningar eller trådar.

Kontrollera också om klienten utför flera återförsök och undersöka orsaken om det är det. För att avgöra om klienten utför flera återförsök kan du:

Granska loggar. Om flera återförsök görs visas flera åtgärder med samma klientbegärans-ID.
Granska klientloggarna. Utförlig loggning anger att ett nytt försök har gjorts.
Felsök koden och kontrollera egenskaperna för objektet som OperationContext är associerat med begäran. Om åtgärden har gjorts RequestResults på nytt innehåller egenskapen flera unika begäranden. Du kan också kontrollera start- och sluttiderna för varje begäran.

Om det inte finns några problem i klienten bör du undersöka potentiella nätverksproblem som paketförlust. Du kan använda verktyg som Wireshark för att undersöka nätverksproblem.

Mått visar hög SuccessServerLatency

När det gäller hög SuccessServerLatency för begäranden om blobnedladdning bör du använda lagringsloggarna för att se om det finns upprepade begäranden för samma blob (eller uppsättning blobar). För begäranden om blobuppladdning bör du undersöka vilken blockstorlek klienten använder (till exempel kan block som är mindre än 64 K i storlek resultera i omkostnader om inte läsningarna också är i mindre än 64 K segment) och om flera klienter laddar upp block till samma blob parallellt. Du bör också kontrollera måtten per minut för toppar i antalet begäranden som resulterar i att skalbarhetsmålen per sekund överskrids.

Om du ser hög SuccessServerLatency för begäranden om blobnedladdning när det finns upprepade begäranden för samma blob eller uppsättning blobar kan du överväga att cachelagra dessa blobar med hjälp av Azure Cache eller Azure Content Delivery Network (CDN). För uppladdningsbegäranden kan du förbättra dataflödet med hjälp av en större blockstorlek. För frågor till tabeller är det också möjligt att implementera cachelagring på klientsidan på klienter som utför samma frågeåtgärder och där data inte ändras ofta.

Höga SuccessServerLatency-värden kan också vara ett symptom på dåligt utformade tabeller eller frågor som resulterar i genomsökningsåtgärder eller som följer antimönstret för tillägg/förberedelse.

Obs!

Du hittar en omfattande checklista för prestanda från Microsoft Azure Storage checklista för prestanda och skalbarhet.

Du upplever oväntade fördröjningar i meddelandeleveransen i en kö

Om det uppstår en fördröjning mellan den tid då ett program lägger till ett meddelande i en kö och den tid det blir tillgängligt att läsa från kön, utför du följande steg för att diagnostisera problemet:

Kontrollera att programmet har lagt till meddelandena i kön. Kontrollera att programmet inte försöker AddMessage använda metoden igen flera gånger innan det lyckas.
Kontrollera att det inte finns någon klocksnedställning mellan arbetsrollen som lägger till meddelandet i kön och arbetsrollen som läser meddelandet från kön. En klocksnedställning gör att det verkar som om bearbetningen är försenad.
Kontrollera om arbetsrollen som läser meddelandena från kön misslyckas. Om en köklient anropar GetMessage metoden men inte svarar med en bekräftelse förblir meddelandet osynligt i kön tills invisibilityTimeout perioden går ut. Nu blir meddelandet tillgängligt för bearbetning igen.
Kontrollera om kölängden växer över tid. Detta kan inträffa om du inte har tillräckligt med personal för att bearbeta alla meddelanden som andra arbetare placerar i kön. Kontrollera också måtten för att se om borttagningsbegäranden misslyckas och antalet avfrågefel för meddelanden, vilket kan tyda på upprepade misslyckade försök att ta bort meddelandet.
Granska lagringsloggarna för eventuella köåtgärder som har högre värden än förväntat för E2ELatency och ServerLatency under en längre tidsperiod än vanligt.

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.