Problemen met taakprestaties van Stream Analytics oplossen met behulp van metrische gegevens en dimensies

Om de gezondheid van een Azure Stream Analytics-baan te begrijpen, moet je weten hoe je de metrics en dimensies van de functie gebruikt. Je kunt de metrische gegevens en dimensies waarin je geïnteresseerd bent ophalen uit Azure Portal, de Visual Studio Code Stream Analytics-extensie of een SDK.

Watermarkvertraging en achterstallige invoergebeurtenissen zijn de belangrijkste meetwaarden die de prestaties van een Stream Analytics-taak bepalen. Als de watermarkvertraging van je job voortdurend toeneemt en invoer-gebeurtenissen zich ophopen, kan de job het tempo van de binnenkomende invoer-gebeurtenissen niet bijhouden en niet op tijd uitvoer genereren.

Dit artikel laat zien hoe je Stream Analytics jobmetrics en -dimensies in het Azure-portaal kunt gebruiken om de prestaties van een taak te onderzoeken. De volgende secties bespreken verschillende voorbeelden die beginnen met de Watermark Delay-metriek om veelvoorkomende prestatieproblemen te diagnosticeren.

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

Als de watermerkvertraging van je embarrassingly parallelle taak gestaag toeneemt, open Metrics in de Azure-portal. Gebruik vervolgens deze stappen om te achterhalen of de oorzaak een gebrek aan data is in sommige partities van je invoerbron:

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

    Schermafbeelding van een grafiek die de watermarkvertraging uitgesplitst naar partitie-id toont wanneer er geen invoer is in een partitie.

  2. Controleer of er inputdata ontbreekt voor deze partitie. Selecteer de metriek Invoergebeurtenissen en filter deze op deze specifieke partitie-ID.

    Schermopname van een grafiek met invoerevenementen die worden gesplitst op partitie-id voor het geval van geen invoer in een partitie.

De watermerkvertraging voor deze partitie neemt toe omdat er geen invoergebeurtenissen naar deze partitie stromen. Als het tolerantievenster van uw taak voor te laat binnenkomende gegevens enkele uren bedraagt en er geen invoergegevens naar een partitie stromen, is het te verwachten dat de watermerkvertraging voor die partitie blijft toenemen totdat deze het venster voor late binnenkomst bereikt.

Als je late aankomstvenster bijvoorbeeld zes uur is en de invoerdata niet naar invoerpartitie 1 stroomt, zal de watermerkvertraging voor uitvoerpartitie 1 toenemen tot zes uur. Controleer of je invoerbron data produceert zoals verwacht.

Scheefheid in invoergegevens veroorzaakt een grote watermerkvertraging

Wanneer je embarrassingly parallel taak een hoge watermarkvertraging heeft, splits dan eerst de metriek Watermark Delay uit naar de dimensie Partition ID. Bepaal vervolgens of alle partities een hoge watermarkvertraging hebben, of slechts een paar.

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.

Schermafbeelding van een grafiek met watermerkvertraging uitgesplitst naar partitie-ID in het geval van gegevensscheefheid.

Controleer hoe de invoergegevens eruitzien over deze partities door de Input Events-metriek te splitsen naar partitie-ID:

Schermopname van een grafiek waarin invoergebeurtenissen worden gesplitst op partitie-id voor het geval van scheeftrekken van gegevens.

In het voorgaande voorbeeld ontvangen de partities (0 en 1) met een hoge watermerkvertraging aanzienlijk meer invoerdata dan de andere partities. Deze voorwaarde wordt data skew genoemd. De streamingnodes die de partities met data skew verwerken, verbruiken meer CPU- en geheugenresources dan de andere, zoals de volgende screenshot laat zien.

Schermopname van een grafiek die het resourcegebruik van partities met een scheve gegevensverdeling toont.

Streaming-nodes die partities met een hogere dataskew verwerken, tonen een hogere CPU-% benutting en SU (geheugen) % benutting. Deze druk op de hulpbronnen beïnvloedt de prestaties van het werk en verhoogt de vertraging in het watermerk. Om het te voorkomen, herpartitioneer je je invoerdata gelijkmatiger.

Je kunt dit probleem ook debuggen door gebruik te maken van het fysieke jobdiagram. Voor meer informatie, zie Fysiek taakdiagram: Identificeer de ongelijke verspreide invoergebeurtenissen (data-skew).

Overbelaste CPU of geheugen verhoogt de watermerkvertraging

Wanneer een gênant parallelle klus een toenemende watermerkvertraging heeft, kan die vertraging alle partities treffen, niet slechts één of meerdere. Om te bevestigen dat jouw baan in deze situatie verkeert, gebruik je deze stappen:

  1. Splits de metriek Watermark Delay op Partitie-ID. Voorbeeld:

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

  2. Splits de Input Events-metriek op partitie-ID om te bevestigen of er datascheef is in de invoerdata voor elke partitie.

  3. Controleer de CPU % Utilization en SU (Memory) % Utilization metrics om te zien of de benutting te hoog is in alle streamingnodes.

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

  4. Als beide metrics hoog zijn (meer dan 80 procent) in alle streaming-nodes, kun je concluderen dat elke streaming-node een grote hoeveelheid data verwerkt.

    Controleer hoeveel partities aan één streamingnode zijn toegewezen met behulp van de Input Events-metriek . Filteren op de ID van het streamingknooppunt met de dimensie Knooppuntnaam, en splitsen op Partitie-id.

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

  5. In de voorgaande schermopname ziet u dat vier partities worden toegewezen aan één streamingknooppunt dat ongeveer 90 tot 100 procent van de resource van het streamingknooppunt in beslag neemt. Gebruik een vergelijkbare aanpak om de rest van de streamingnodes te controleren en te bevestigen dat zij ook data verwerken van vier partities.

Verminder het aantal partities dat elke streamingnode verwerkt om de invoerdata per node te verlagen. Om dit te doen, verdubbel je het aantal SU's zodat elke streamingknoop gegevens van twee partities verwerkt, of verviervoudig je de SU's zodat elke stromende knoop gegevens van één partitie verwerkt. 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? Partitioneer uw invoer opnieuw met meer partities om de hoeveelheid gegevens in elke partitie te verminderen. Zie Repartitioning gebruiken om Azure Stream Analytics-taken te optimaliseren voor meer informatie.

Je kunt dit probleem ook debuggen met het fysieke taakdiagram. Voor meer informatie, zie Physical job diagram: Identificeer de oorzaak van overbelaste CPU of geheugen.

Verwante onderwerpen

  • Last updated on