Problemen met prestaties in Azure Storage-accounts oplossen

Artikel
04/10/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 tonen de gemiddelde tijd 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 (het omvat daarom netwerklatentie zodra de aanvraag de opslagservice bereikt). SuccessServerLatency is een meting van alleen de verwerkingstijd en sluit daarom netwerklatentie met betrekking tot communicatie met de client uit.
De metrische gegevens voor uitgaand verkeer en inkomend verkeer geven de totale hoeveelheid gegevens weer, in bytes, die binnenkomen en uitgaan 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 is 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 nader moet worden onderzocht.

In de Azure Portal kunt u waarschuwingsregels toevoegen die u waarschuwen wanneer een van de metrische prestatiegegevens voor deze service onder een door u opgegeven drempelwaarde valt of overschrijdt.

Prestatieproblemen vaststellen

De prestaties van een toepassing kunnen subjectief zijn, met name vanuit gebruikersperspectief. Daarom is het belangrijk om basislijngegevens beschikbaar te hebben om te bepalen waar zich mogelijk een prestatieprobleem voordoet. Veel factoren kunnen van invloed zijn op de prestaties van een Azure Storage-service vanuit het perspectief van de clienttoepassing. Deze factoren kunnen actief zijn in de opslagservice, de client of de netwerkinfrastructuur. Daarom is het belangrijk om een strategie te hebben voor het identificeren van de oorzaak van het prestatieprobleem.

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

Metrische gegevens tonen een hoge SuccessE2ELatency en een lage SuccessServerLatency

In sommige gevallen vindt u dat SuccessE2ELatency hoger is dan de SuccessServerLatency. De opslagservice berekent alleen de metrische SuccessE2ELatency voor geslaagde aanvragen en omvat, 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 komen doordat de clienttoepassing traag reageert of door omstandigheden op het netwerk.

Opmerking

U kunt ook E2ELatency en ServerLatency weergeven voor afzonderlijke opslagbewerkingen in de logboekgegevens voor opslaglogboeken.

Prestatieproblemen van client onderzoeken

Mogelijke redenen waarom de client traag reageert, zijn beperkte beschikbare verbindingen of threads of weinig resources, zoals CPU, geheugen of netwerkbandbreedte. U kunt het probleem mogelijk oplossen door de clientcode efficiënter te maken (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 een hoge SuccessE2ELatency veroorzaken in vergelijking met SuccessServerLatency. Zie het bericht Algoritme van Nagle 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 .NET-gerelateerde prestatieknelpunten 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

Een hoge end-to-end latentie die door het netwerk wordt veroorzaakt, wordt meestal veroorzaakt door tijdelijke omstandigheden. U kunt zowel tijdelijke als permanente netwerkproblemen, zoals verwijderde pakketten, onderzoeken met behulp van hulpprogramma's zoals Wireshark.

Metrische gegevens tonen een lage SuccessE2ELatency en een 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 niet worden doorgevoerd in de blobservice.

Een mogelijke reden waarom de client het verzenden van aanvragen vertraagt, 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 dat zo is. Om te bepalen of de client meerdere nieuwe pogingen uitvoert, kunt u het volgende doen:

Bekijk logboeken. 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.
Foutopsporing in uw code en controleer de eigenschappen van het OperationContext object dat aan de aanvraag is gekoppeld. Als de bewerking opnieuw is geprobeerd, bevat de RequestResults eigenschap meerdere unieke aanvragen. U kunt ook de begin- en eindtijd voor elke aanvraag controleren.

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

Metrische gegevens tonen een 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 aanvragen voor het uploaden van blob moet u onderzoeken welke blokgrootte de client gebruikt (blokken van minder dan 64 K kunnen bijvoorbeeld leiden tot overhead, tenzij de leesbewerkingen zich ook in segmenten van minder dan 64 K bevinden) en of meerdere clients blokken parallel uploaden naar dezelfde blob. U moet ook de metrische gegevens per minuut controleren op pieken in het aantal aanvragen waardoor de schaalbaarheidsdoelen per seconde worden overschreden.

Als u hoge SuccessServerLatency ziet voor blob-downloadaanvragen 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 door een grotere blokgrootte te gebruiken. Voor query's naar tabellen is het ook mogelijk om caching aan de clientzijde te implementeren op clients die dezelfde querybewerkingen uitvoeren en waar de gegevens niet regelmatig worden gewijzigd.

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

Opmerking

U vindt een uitgebreide controlelijst voor prestaties in Microsoft Azure Storage Controlelijst voor prestaties en schaalbaarheid.

U ondervindt onverwachte vertragingen bij de bezorging van berichten in een wachtrij

Als u een vertraging ondervindt tussen het moment dat een toepassing een bericht aan een wachtrij toevoegt en het tijdstip waarop het bericht uit de wachtrij kan worden gelezen, 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 niet meerdere keren opnieuw probeert voordat het lukt.
Controleer of er geen klokverschil is tussen de werkrol die het bericht toevoegt aan de wachtrij en de werkrol die het bericht uit de wachtrij leest. Een scheefheid van de klok zorgt ervoor dat het lijkt 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 is verstreken. Op dit moment is het bericht weer beschikbaar voor verwerking.
Controleer of de wachtrijlengte in de loop van de tijd toeneemt. Dit kan gebeuren als u onvoldoende werknemers beschikbaar hebt om alle berichten te verwerken die andere werknemers in de wachtrij plaatsen. Controleer ook de metrische gegevens om te zien of verwijderingsaanvragen mislukken en het aantal berichten in de wachtrij, wat kan duiden op herhaalde mislukte pogingen om het bericht te verwijderen.
Controleer de opslaglogboeken op wachtrijbewerkingen die over een langere periode dan normaal een hogere E2ELatency - en ServerLatency-waarden hebben.

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 Feedback-community van Azure.

Share via