Problemen met prestaties in Azure-opslagaccounts oplossen

Artikel
11/20/2024

Dit artikel helpt u bij het onderzoeken van onverwachte wijzigingen in gedrag (zoals tragere reactietijden dan normaal). Deze wijzigingen in gedrag kunnen vaak worden geïdentificeerd door metrische opslaggegevens in Azure Monitor te bewaken. Zie de volgende artikelen voor algemene informatie over het gebruik van metrische gegevens en logboeken in Azure Monitor:

Prestaties bewaken

Als u de prestaties van de opslagservices wilt bewaken, kunt u de volgende metrische gegevens gebruiken:

De metrische gegevens SuccessE2ELatency en SuccessServerLatency geven de gemiddelde tijd aan die de opslagservice of het API-bewerkingstype nodig heeft om aanvragen te verwerken. SuccessE2ELatency is een meting van end-to-end latentie die de tijd omvat die nodig is om de aanvraag te lezen en het antwoord te verzenden naast de tijd die nodig is om de aanvraag te verwerken (daarom omvat deze netwerklatentie zodra de aanvraag de opslagservice bereikt). SuccessServerLatency is een meting van alleen de verwerkingstijd en sluit daarom alle netwerklatentie met betrekking tot de communicatie met de client uit.
De metrische gegevens uitgaand en inkomend verkeer tonen de totale hoeveelheid gegevens, in bytes, binnenkomend naar en uitgaand van uw opslagservice of via een specifiek API-bewerkingstype .
De metrische waarde Transacties toont het totale aantal aanvragen dat de opslagservice van de API-bewerking ontvangt. Transacties zijn het totale aantal aanvragen dat de opslagservice ontvangt.

U kunt controleren op onverwachte wijzigingen in een van deze waarden. Deze wijzigingen kunnen duiden op een probleem dat verder moet worden onderzocht.

In Azure Portal kunt u waarschuwingsregels toevoegen die u waarschuwen wanneer een van de metrische prestatiegegevens voor deze service lager is dan of hoger is dan een drempelwaarde die u opgeeft.

Prestatieproblemen diagnosticeren

De prestaties van een toepassing kunnen subjectief zijn, met name vanuit het perspectief van een gebruiker. Daarom is het belangrijk dat u metrische basislijngegevens beschikbaar hebt om te bepalen waar zich mogelijk een prestatieprobleem voordoet. Veel factoren kunnen van invloed zijn op de prestaties van een Azure-opslagservice vanuit het perspectief van de clienttoepassing. Deze factoren werken mogelijk in de opslagservice, de client of de netwerkinfrastructuur. Daarom is het belangrijk dat u een strategie hebt voor het identificeren van de oorsprong van het prestatieprobleem.

Nadat u de waarschijnlijke locatie van de oorzaak van het prestatieprobleem van de metrische gegevens hebt geïdentificeerd, kunt u vervolgens de logboekbestanden gebruiken om gedetailleerde informatie te vinden om het probleem verder te diagnosticeren en op te lossen.

Metrische gegevens tonen hoge SuccessE2ELatency en lage SuccessServerLatency

In sommige gevallen kan het zijn dat SuccessE2ELatency hoger is dan successServerLatency. De opslagservice berekent alleen de metrische waarde SuccessE2ELatency voor geslaagde aanvragen en bevat, in tegenstelling tot SuccessServerLatency, de tijd die de client nodig heeft om de gegevens te verzenden en bevestiging van de opslagservice te ontvangen. Daarom kan een verschil tussen SuccessE2ELatency en SuccessServerLatency worden veroorzaakt doordat de clienttoepassing traag reageert of vanwege omstandigheden in het netwerk.

Notitie

U kunt ook E2ELatency en ServerLatency weergeven voor afzonderlijke opslagbewerkingen in de logboekgegevens van logboekregistratie van opslag.

Problemen met clientprestaties onderzoeken

Mogelijke redenen waarom de client langzaam reageert, zijn onder andere dat er beperkte beschikbare verbindingen of threads zijn of dat er weinig resources beschikbaar zijn, zoals CPU, geheugen of netwerkbandbreedte. U kunt het probleem mogelijk oplossen door de clientcode te wijzigen zodat deze efficiënter is (bijvoorbeeld door asynchrone aanroepen naar de opslagservice te gebruiken) of door een grotere virtuele machine met meer kernen en meer geheugen te gebruiken.

Voor de tabel- en wachtrijservices kan het Nagle-algoritme ook leiden tot een hoog SuccessE2ELatency in vergelijking met SuccessServerLatency. Zie het bericht Nagle's Algoritme is niet vriendelijk voor kleine aanvragen voor meer informatie. U kunt het Nagle-algoritme in code uitschakelen met behulp van de ServicePointManager klasse in de System.Net naamruimte. U moet dit doen voordat u de tabel- of wachtrijservices in uw toepassing aanroept, omdat dit geen invloed heeft op verbindingen die al zijn geopend. Het volgende voorbeeld is afkomstig van de Application_Start methode in een werkrol:

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

Controleer de logboeken aan de clientzijde om te zien hoeveel aanvragen uw clienttoepassing verzendt en controleer op algemene knelpunten in de prestaties van .NET in uw client, zoals CPU, .NET garbagecollection, netwerkgebruik of geheugen. Zie Foutopsporing, tracering en profilering als uitgangspunt voor het oplossen van problemen met .NET-clienttoepassingen.

Problemen met netwerklatentie onderzoeken

Normaal gesproken wordt een hoge end-to-endlatentie veroorzaakt door het netwerk vanwege tijdelijke omstandigheden. U kunt zowel tijdelijke als permanente netwerkproblemen onderzoeken, zoals verwijderde pakketten, met behulp van hulpprogramma's zoals Wireshark.

Metrische gegevens tonen lage SuccessE2ELatency en lage SuccessServerLatency, maar de client ondervindt hoge latentie

In dit scenario is de meest waarschijnlijke oorzaak een vertraging in de opslagaanvraag die de opslagservice bereikt. U moet onderzoeken waarom aanvragen van de client deze niet doorbrengen naar de blobservice.

Een mogelijke reden voor het uitstellen van verzendaanvragen door de client is dat er een beperkt aantal beschikbare verbindingen of threads is.

Controleer ook of de client meerdere nieuwe pogingen uitvoert en onderzoek de reden als dit het is. Als u wilt bepalen of de client meerdere nieuwe pogingen uitvoert, kunt u het volgende doen:

Logboeken onderzoeken. Als er meerdere nieuwe pogingen worden uitgevoerd, ziet u meerdere bewerkingen met dezelfde clientaanvraag-id's.
Controleer de clientlogboeken. Uitgebreide logboekregistratie geeft aan dat er een nieuwe poging is opgetreden.
Fouten opsporen in uw code en de eigenschappen controleren van het OperationContext object dat is gekoppeld aan de aanvraag. Als de bewerking opnieuw is geprobeerd, bevat de RequestResults eigenschap meerdere unieke aanvragen. U kunt ook de begin- en eindtijden voor elke aanvraag controleren.

Als er geen problemen zijn in de client, moet u potentiële netwerkproblemen onderzoeken, zoals pakketverlies. U kunt hulpprogramma's zoals Wireshark gebruiken om netwerkproblemen te onderzoeken.

Metrische gegevens tonen hoge SuccessServerLatency

In het geval van hoge SuccessServerLatency voor blob-downloadaanvragen, moet u de Opslaglogboeken gebruiken om te zien of er herhaalde aanvragen zijn voor dezelfde blob (of set blobs). Voor blob-uploadaanvragen moet u onderzoeken welke blokgrootte de client gebruikt (blokken van minder dan 64 K in grootte kunnen bijvoorbeeld leiden tot overhead, tenzij de leesbewerkingen zich ook in minder dan 64 K-segmenten bevinden) en als meerdere clients blokken parallel uploaden naar dezelfde blob. U moet ook de metrische gegevens per minuut controleren op pieken in het aantal aanvragen dat resulteert in het overschrijden van de schaalbaarheidsdoelen per seconde.

Als u hoge SuccessServerLatency voor blob-downloadaanvragen ziet wanneer er herhaalde aanvragen zijn voor dezelfde blob of set blobs, kunt u overwegen deze blobs in de cache op te nemen met behulp van Azure Cache of het Azure Content Delivery Network (CDN). Voor uploadaanvragen kunt u de doorvoer verbeteren met behulp van een grotere blokgrootte. Voor query's naar tabellen is het ook mogelijk om caching aan clientzijde te implementeren op clients die dezelfde querybewerkingen uitvoeren en waar de gegevens niet vaak veranderen.

Hoge SuccessServerLatency-waarden kunnen ook een symptoom zijn van slecht ontworpen tabellen of query's die resulteren in scanbewerkingen of die het toevoeg-/voorbereide antipatroon volgen.

Notitie

U vindt een uitgebreide controlelijst voor prestaties van Microsoft Azure Storage en de controlelijst voor schaalbaarheid.

U ondervindt onverwachte vertragingen bij het bezorgen van berichten in een wachtrij

Als u een vertraging ondervindt tussen het moment dat een toepassing een bericht toevoegt aan een wachtrij en de tijd die beschikbaar is om uit de wachtrij te lezen, voert u de volgende stappen uit om het probleem vast te stellen:

Controleer of de toepassing de berichten aan de wachtrij heeft toegevoegd. Controleer of de toepassing de AddMessage methode meerdere keren opnieuw probeert uit te voeren voordat deze slaagt.
Controleer of er geen klokverschil is tussen de werkrol waarmee het bericht wordt toegevoegd aan de wachtrij en de werkrol die het bericht uit de wachtrij leest. Een klok scheeftrekken maakt het alsof er een vertraging in de verwerking is.
Controleer of de werkrol die de berichten uit de wachtrij leest, mislukt. Als een wachtrijclient de GetMessage methode aanroept, maar niet reageert met een bevestiging, blijft het bericht onzichtbaar in de wachtrij totdat de invisibilityTimeout periode verloopt. Op dit moment wordt het bericht weer beschikbaar voor verwerking.
Controleer of de wachtrijlengte na verloop van tijd groeit. Dit kan gebeuren als u niet voldoende werkrollen hebt om alle berichten te verwerken die andere werknemers in de wachtrij plaatsen. Controleer ook de metrische gegevens om te zien of verwijderaanvragen mislukken en het aantal wachtrijen op berichten, wat kan duiden op herhaalde mislukte pogingen om het bericht te verwijderen.
Bekijk de opslaglogboeken voor wachtrijbewerkingen met een hogere dan verwachte E2ELatency - en ServerLatency-waarden gedurende een langere periode dan normaal.

Zie ook

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.

Delen via