Felsöka prestanda i Azure Storage-konton

Artikel
11/20/2024

Den här artikeln hjälper dig att undersöka oväntade ändringar i beteendet (till exempel långsammare svarstider än vanligt). Dessa beteendeändringar 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 relaterade till kommunikation med klienten.
Måtten Utgående 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

Upplevelsen av programprestanda kan vara högst subjektiv, särskilt från 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-lagringstjä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 det hända 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 antingen på att klientprogrammet svarar långsamt eller på grund av villkor i nätverket.

Kommentar

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 CPU, 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 går vidare 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ärande-ID.
Granska klientloggarna. Utförlig loggning indikerar 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 på nytt innehåller egenskapen RequestResults 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, till exempel paketförlust. Du kan använda verktyg som Wireshark för att undersöka nätverksproblem.

Mått visar hög SuccessServerLatency

Vid 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). När det gäller förfrågningar om uppladdning kan du förbättra dataflödet genom att använda 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.

Kommentar

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

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

Om det uppstår en fördröjning mellan den tidpunkt 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, gör du följande för att diagnostisera problemet:

Kontrollera att programmet har lagt till meddelandena i kön. Kontrollera att programmet inte försöker AddMessage metoden igen flera gånger innan det lyckas.
Kontrollera att det inte finns någon klockförskjutning mellan arbetsrollen som lägger till meddelandet i kön och arbetsrollen som läser meddelandet från kön. Ett klocksnedvridning gör att det ser ut som om bearbetningen fördröjs.
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 arbetare tillgängliga 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 på meddelanden, vilket kan tyda på upprepade misslyckade försök att ta bort meddelandet.
Undersök lagringsloggarna för alla 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.

Dela via