Prestaties van Stream Analytics-taken analyseren met behulp van metrische gegevens en dimensies

Als u de status van een Azure Stream Analytics-taak wilt begrijpen, is het belangrijk om te weten hoe u de metrische gegevens en dimensies van de taak gebruikt. U kunt de Azure Portal, de Stream Analytics-extensie van Visual Studio Code of een SDK gebruiken om de metrische gegevens en dimensies op te halen waarin u geïnteresseerd bent.

Dit artikel laat zien hoe u metrische gegevens en dimensies van Stream Analytics-taken gebruikt om de prestaties van een taak te analyseren via de Azure Portal.

Watermerkvertraging en vertraagde invoergebeurtenissen zijn de belangrijkste metrische gegevens om de prestaties van uw Stream Analytics-taak te bepalen. Als de vertraging van het watermerk van uw taak voortdurend toeneemt en invoergebeurtenissen worden achtergehouden, kan uw taak de snelheid van invoergebeurtenissen niet bijhouden en tijdig uitvoer produceren.

Laten we enkele voorbeelden bekijken om de prestaties van een taak te analyseren via de metrische gegevens watermerkvertraging als uitgangspunt.

Geen invoer voor een bepaalde partitie verhoogt de vertraging van het taakwatermerk

Als de watermerkvertraging van uw gênant parallelle taak gestaag toeneemt, gaat u naar Metrische gegevens. Gebruik vervolgens deze stappen om erachter te komen of de hoofdoorzaak een gebrek aan gegevens in sommige partities van uw invoerbron is:

  1. Controleer welke partitie de toenemende watermerkvertraging heeft. Selecteer het metrische gegeven Watermerkvertraging en splits deze op basis van de dimensie Partitie-id . In het volgende voorbeeld heeft partitie 465 een hoge watermerkvertraging.

    Schermopname van een grafiek met een vertraging bij het splitsen van watermerken op partitie-id voor het geval er geen invoer in een partitie is.

  2. Controleer of er invoergegevens ontbreken voor deze partitie. Selecteer de metrische gegevens Input Events en filter deze op deze specifieke partitie-id.

    Schermopname van een grafiek waarin invoerevenementen worden gesplitst op partitie-id voor het geval er geen invoer in een partitie is.

Welke verdere actie kunt u ondernemen?

De watermerkvertraging voor deze partitie neemt toe omdat er geen invoergebeurtenissen naar deze partitie stromen. Als het tolerantievenster van uw taak voor late aankomsten enkele uren is en er geen invoergegevens naar een partitie stromen, wordt verwacht dat de watermerkvertraging voor die partitie blijft toenemen totdat het venster voor late aankomst is bereikt.

Als uw venster voor late aankomst bijvoorbeeld 6 uur is en de invoergegevens niet naar invoerpartitie 1 stromen, neemt de watermerkvertraging voor uitvoerpartitie 1 toe totdat deze 6 uur bereikt. U kunt controleren of uw invoerbron gegevens produceert zoals verwacht.

Scheeftrekken van invoergegevens veroorzaakt een hoge watermerkvertraging

Zoals vermeld in het vorige geval, wanneer uw gênant parallelle taak een hoge watermerkvertraging heeft, moet u eerst de metrische gegevens voor watermerkvertraging splitsen op basis van de dimensie Partitie-id . U kunt vervolgens bepalen of alle partities een hoge watermerkvertraging hebben, of slechts enkele.

In het volgende voorbeeld hebben partities 0 en 1 een hogere watermerkvertraging (ongeveer 20 tot 30 seconden) dan de andere acht partities. De watermerkvertragingen van de andere partities zijn altijd stabiel op ongeveer 8 tot 10 seconden.

Schermopname van een grafiek met watermerkvertraging gesplitst op partitie-id voor het geval er sprake is van scheeftrekken van gegevens.

Laten we eens kijken hoe de invoergegevens eruit zien voor al deze partities met de metrische invoer gebeurtenissen gesplitst op partitie-id:

Schermopname van een grafiek met invoergebeurtenissen gesplitst op partitie-id voor het geval er sprake is van scheeftrekken van gegevens.

Welke verdere actie kunt u ondernemen?

Zoals weergegeven in het voorbeeld, ontvangen de partities (0 en 1) met een hoge watermerkvertraging aanzienlijk meer invoergegevens dan andere partities. We noemen dit scheeftrekken van gegevens. De streamingknooppunten die de partities met gegevensverschil verwerken, moeten meer CPU- en geheugenresources verbruiken dan andere, zoals wordt weergegeven in de volgende schermopname.

Schermopname van een grafiek met het resourcegebruik van partities met gegevensscheefheid.

Streamingknooppunten die partities verwerken met een hogere scheeftrekken van gegevens, vertonen een hoger CPU- en/of SU-gebruik (Streaming Unit). Dit gebruik heeft invloed op de prestaties van de taak en verhoogt de watermerkvertraging. Om dit te verhelpen, moet u uw invoergegevens gelijkmatiger partitioneren.

U kunt dit probleem ook opsporen met een fysiek taakdiagram. Zie Fysiek taakdiagram: Identificeer de ongelijke gedistribueerde invoergebeurtenissen (gegevensscheefheid).

Overbelaste CPU of geheugen verhoogt watermerkvertraging

Wanneer een gênant parallelle taak een toenemende watermerkvertraging heeft, kan dit niet alleen gebeuren op een of meer partities, maar op alle partities. Hoe bevestigt u dat uw taak in deze zaak valt?

  1. Splits de meetwaarde Watermerkvertraging op partitie-id. Bijvoorbeeld:

    Schermopname van een grafiek met watermerkvertraging gesplitst op partitie-id voor het geval van overbelaste CPU en geheugen.

  2. Splits de metrische gegevens voor Invoergebeurtenissen op partitie-id om te bevestigen of er sprake is van scheeftrekken in de invoergegevens voor elke partitie.

  3. Controleer het CPU- en SU-gebruik om te zien of het gebruik in alle streamingknooppunten te hoog is.

    Schermopname van een grafiek waarin het CPU- en geheugengebruik wordt gesplitst op knooppuntnaam voor het geval van overbelaste CPU en geheugen.

  4. Als het CPU- en SU-gebruik zeer hoog is (meer dan 80 procent) op alle streamingknooppunten, kunt u concluderen dat deze taak een grote hoeveelheid gegevens bevat die binnen elk streamingknooppunt wordt verwerkt.

    U kunt verder controleren hoeveel partities zijn toegewezen aan één streamingknooppunt door de metrische gegevens voor invoerevenementen te controleren. Filter op streamingknooppunt-id met de dimensie Knooppuntnaam en splits op partitie-id.

    Schermopname van een grafiek met het aantal partities op één streamingknooppunt voor overbelaste CPU en geheugen.

  5. In de voorgaande schermopname ziet u dat er vier partities zijn toegewezen aan één streamingknooppunt dat ongeveer 90 tot 100 procent van de resource van het streamingknooppunt in beslag neemt. U kunt een vergelijkbare benadering gebruiken om de rest van de streamingknooppunten te controleren om te bevestigen dat ze ook gegevens van vier partities verwerken.

Welke verdere actie kunt u ondernemen?

Mogelijk wilt u het aantal partities voor elk streamingknooppunt verminderen om de invoergegevens voor elk streamingknooppunt te verminderen. Om dit te bereiken, kunt u de RU's verdubbelen om elk streamingknooppunt gegevens van twee partities te laten verwerken. Of u kunt de RU's verviervoudigen om elk streamingknooppunt gegevens van één partitie te laten verwerken. Zie Streaming-eenheden begrijpen en aanpassen voor informatie over de relatie tussen SU-toewijzing en het aantal streamingknooppunten.

Wat moet u doen als de watermerkvertraging nog steeds toeneemt wanneer één streamingknooppunt gegevens van één partitie verwerkt? Deel uw invoer opnieuw met meer partities om de hoeveelheid gegevens in elke partitie te verminderen. Zie Opnieuw partitioneren gebruiken om Azure Stream Analytics-taken te optimaliseren voor meer informatie.

U kunt dit probleem ook opsporen met een fysiek taakdiagram. Zie Fysiek taakdiagram: de oorzaak van overbelaste CPU of geheugen identificeren.

Volgende stappen