Risolvere i problemi di prestazioni dei processi di Stream Analytics tramite metriche e dimensioni

Per comprendere la salute di un lavoro Analisi di flusso di Azure, devi sapere come utilizzare le metriche e le dimensioni del lavoro. Puoi ottenere le metriche e le dimensioni che ti interessano dal portale Azure, dall'estensione Visual Studio Code Stream Analytics o da un SDK.

Il ritardo limite e gli eventi di input accumulati sono le metriche principali che determinano le prestazioni di un processo di Analisi di flusso. Se il ritardo limite del processo aumenta continuamente e gli eventi di input si accumulano, il processo non riesce a tenere il passo con la frequenza degli eventi di input e non può produrre output in tempo.

Questo articolo ti mostra come utilizzare le metriche e le dimensioni dei job di Stream Analytics nel portale Azure per diagnosticare le prestazioni di un lavoro. Le sezioni seguenti illustrano diversi esempi che partono dalla metrica Watermark Delay per diagnosticare problemi di prestazioni comuni.

L'assenza di input per una determinata partizione aumenta il ritardo limite del processo

Se il ritardo limite del processo perfettamente parallelo aumenta costantemente, aprire Metriche nel portale di Azure. Poi usa questi passaggi per scoprire se la causa principale è la mancanza di dati in alcune partizioni della tua sorgente di input:

  1. Verificare quale partizione presenta un ritardo limite in aumento. Selezionare la metrica ritardo limite e suddividerla in base alla dimensione ID partizione. Nell'esempio seguente, la partizione 465 presenta un ritardo limite elevato.

    Schermata di un grafico che mostra il ritardo del watermark suddiviso per ID della partizione nel caso in cui non vi sia alcun input in una partizione.

  2. Controlla se mancano dati di input per questa partizione. Selezionare la metrica Eventi di input e filtrarla in base a questo ID di partizione specifico.

    Schermata di un grafico che mostra gli eventi di input suddivisi per ID partizione nel caso di assenza di input in una partizione.

Il ritardo limite per questa partizione aumenta perché non vengono trasmessi eventi di input a questa partizione. Se la finestra di tolleranza del processo per gli arrivi in ritardo è di diverse ore e non vengono trasmessi dati di input a una partizione, è previsto che il ritardo limite per tale partizione continui ad aumentare fino a raggiungere la finestra di arrivo in ritardo.

Ad esempio, se la finestra di arrivo in ritardo è di sei ore e non vengono trasmessi dati di input alla partizione di input 1, il ritardo limite per la partizione di output 1 aumenterà fino a raggiungere sei ore. Controlla se la tua sorgente di input produce i dati come previsto.

L'asimmetria dei dati di input causa un ritardo limite elevato

Quando un processo embarrassingly parallel presenta un ritardo limite elevato, suddividere innanzitutto la metrica ritardo limite in base alla dimensione ID partizione. Poi identifica se tutte le partizioni presentano un ritardo del watermark alto oppure solo alcune.

Nell'esempio seguente, le partizioni 0 e 1 presentano una latenza della watermark più elevata (circa 20-30 secondi) rispetto alle altre otto partizioni. I ritardi limite delle altre partizioni rimangono sempre stabili intorno a 8-10 secondi.

Screenshot di un grafico che mostra ritardo limite suddiviso in base a ID partizione nel caso di asimmetria dei dati.

Controlla come appaiono i dati di input tra queste partizioni dividendo la metrica degli Eventi di Input per ID Partizione:

Schermata di un grafico che mostra la suddivisione degli eventi di input in base all'ID della partizione nel caso di squilibrio dei dati.

Nell'esempio precedente, le partizioni (0 e 1) che hanno un ritardo elevato nella filigrana ricevono significativamente più dati in ingresso rispetto alle altre partizioni. Questa condizione è chiamata sfasamento dei dati. I nodi di streaming che elaborano le partizioni con data skew consumano più risorse di CPU e memoria rispetto agli altri, come mostra lo screenshot seguente.

Screenshot di un grafico che mostra l'utilizzo delle risorse delle partizioni con asimmetria dei dati.

I nodi di streaming che elaborano partizioni con maggiore data skew mostrano un utilizzo % CPU e SU (Memory) % Utilizzo più elevato. Questa pressione sulle risorse influisce sulle prestazioni del processo e aumenta il ritardo limite. Per mitigarlo, ripartiziona i dati di input in modo più uniforme.

Puoi anche risolvere questo problema usando il diagramma fisico del lavoro. Per ulteriori informazioni, vedi Diagramma fisico del lavoro: Identificare gli eventi di input distribuiti diseguali (data-skew).

Il sovraccarico della CPU o della memoria aumenta il ritardo del watermark

Quando un processo embarrassingly parallel presenta un ritardo limite in aumento, il ritardo può interessare tutte le partizioni, non solo una o alcune. Per confermare che il tuo lavoro si trova in questa situazione, usa questi passaggi:

  1. Suddividere la metrica ritardo limite in base a ID partizione. Ad esempio:

    Schermata di un grafico che mostra il Watermark Delay suddiviso per ID di partizione nel caso di sovraccarico di CPU e memoria.

  2. Dividi la metrica degli Eventi di Input per ID di Partizione per confermare se c'è un distorsione dei dati di ingresso per ogni partizione.

  3. Controlla le metriche CPU % Utilizzo e SU (Memoria) % Utilizzo per vedere se l'utilizzo è troppo alto in tutti i nodi di streaming.

    Screenshot di un grafico che mostra l'utilizzo di CPU e della memoria diviso in base al nome del nodo per il caso di CPU e memoria sovraccarichi.

  4. Se entrambe le metriche sono alte (oltre l'80 percento) in tutti i nodi di streaming, si può concludere che ogni nodo di streaming sta elaborando una grande quantità di dati.

    Controlla quante partizioni sono allocate a un nodo di streaming usando la metrica Input Events . Filtrare per ID del nodo di streaming con la dimensione Nome del nodo e suddividere per ID partizione.

    Schermata di un grafico che mostra il numero di partizioni su un nodo di streaming nel caso di sovraccarico di CPU e memoria.

  5. Lo screenshot precedente mostra che quattro partizioni vengono allocate a un nodo di streaming che occupa circa il 90-100% della risorsa del nodo di streaming. Usa un approccio simile per controllare gli altri nodi di streaming e confermare che stessero anche processando dati da quattro partizioni.

Ridurre il numero di partizioni gestite da ogni nodo di streaming per diminuire i dati di input per nodo. Per farlo, raddoppiare le SU in modo che ogni nodo di streaming gestisca i dati da due partizioni, oppure quadruplicare le SU in modo che ogni nodo di streaming gestisca i dati di una partizione. Per informazioni sulla relazione tra l'assegnazione delle SU e il numero dei nodi di streaming, vedere Informazioni e modifica delle unità di streaming.

Cosa si dovrebbe fare se il ritardo del watermark continua ad aumentare quando un nodo di streaming sta gestendo dati provenienti da una partizione? Fare una ripartizione degli input con più partizioni per ridurre la quantità di dati in ogni partizione. Per maggiori dettagli, vedere Usare la ripartizione per ottimizzare i processi di Analisi di flusso di Azure.

Puoi anche risolvere questo problema con il diagramma fisico del lavoro. Per maggiori informazioni, vedi Diagramma fisico del lavoro: Identificare la causa del sovraccarico della CPU o della memoria.

Contenuti correlati

  • Ultimo aggiornamento: