Risolvere i problemi relativi a job lenti o bloccati

Questa pagina spiega come risolvere i problemi comuni relativi a job batch e in streaming di Dataflow lenti o bloccati.

Streaming

Se noti i seguenti sintomi, il job di streaming Dataflow potrebbe essere in esecuzione lentamente o essere bloccato:

Utilizza le informazioni riportate nelle sezioni seguenti per identificare e diagnosticare il problema.

Esaminare gli errori ripetuti

In un job di streaming, alcuni errori vengono riprovati a tempo indeterminato. Questi tentativi di nuovo impediscono l'avanzamento della pipeline. Per identificare errori ripetuti, controlla se sono presenti eccezioni nei log dei worker.

Identificare i lavoratori non conformi

Se i worker che elaborano il job di streaming non sono in stato di esecuzione, il job potrebbe essere lento o sembrare bloccato. Per identificare i worker non funzionanti:

Identificare gli elementi in ritardo

Un elemento in ritardo è un elemento di lavoro lento rispetto ad altri elementi di lavoro nella fase. Per informazioni su come identificare e correggere gli elementi in ritardo, consulta Risolvere i problemi relativi agli elementi in ritardo nei job di streaming.

Risolvere i problemi di parallelismo insufficiente

Per scalabilità ed efficienza, Dataflow esegue le fasi della pipeline in parallelo su più worker. L'unità più piccola di elaborazione parallela in Dataflow è una chiave. I messaggi in entrata per ogni fase combinata sono associati a una chiave. La chiave è definita in uno dei seguenti modi:

  • La chiave è definita implicitamente dalle proprietà dell'origine, ad esempio le partizioni Pub/Sub.
  • La chiave è definita esplicitamente dalla logica di aggregazione nella pipeline, ad esempio GroupByKey.

Se la pipeline non dispone di chiavi sufficienti per una determinata fase, limita l'elaborazione parallela. Questa fase potrebbe diventare un collo di bottiglia.

Identificare le fasi con un parallelismo ridotto

Per identificare se la lentezza della pipeline è causata da un parallelismo ridotto, visualizza le metriche di utilizzo della CPU. Se la CPU è bassa, ma distribuita in modo uniforme tra i worker, il job potrebbe avere un parallelismo insufficiente. Se il tuo job utilizza Streaming Engine, per vedere se un livello ha un parallelismo ridotto, nella scheda Metriche job visualizza le metriche di parallelismo. Per ridurre il problema:

  • Nella console Google Cloud, nella pagina Informazioni sul job, utilizza la scheda Autoscaling per verificare se il job ha problemi di ridimensionamento. Se il problema riguarda la scalabilità automatica, consulta Risolvere i problemi di scalabilità automatica di Dataflow.
  • Utilizza il grafico del job per controllare i passaggi della fase. Se la fase legge da un'origine o scrive in un'area di destinazione, esamina la documentazione del servizio dell'origine o dell'area di destinazione. Consulta la documentazione per determinare se il servizio è configurato per una scalabilità sufficiente.

Controllare la presenza di tasti di scelta rapida

Se le attività sono distribuite in modo non uniforme tra i worker e l'utilizzo dei worker è molto irregolare, la pipeline potrebbe avere un hot key. Una hot key è una chiave che ha molti più elementi da elaborare rispetto ad altre chiavi. Per risolvere il problema, esegui uno o più dei seguenti passaggi:

  • Rinomina i dati. Per generare nuove coppie chiave-valore, applica una trasformazione ParDo. Per ulteriori informazioni, consulta la pagina relativa alla trasformazione ParDo in Java o la pagina relativa alla trasformazione ParDo in Python nella documentazione di Apache Beam.
  • Utilizza .withFanout nelle trasformazioni combinate. Per ulteriori informazioni, consulta la classe Combine.PerKey nell'SDK Java o l'operazione with_hot_key_fanout nell'SDK Python.
  • Se hai una pipeline Java che elabora PCollectionsdi grandi volumi e senza limiti, ti consigliamo di procedere nel seguente modo:
    • Utilizza Combine.Globally.withFanout anziché Combine.Globally.
    • Utilizza Combine.PerKey.withHotKeyFanout anziché Count.PerKey.

Verificare la presenza di quota insufficiente

Assicurati di disporre di una quota sufficiente per l'origine e la destinazione. Ad esempio, se la pipeline legge input da Pub/Sub o BigQuery, il progetto Google Cloud potrebbe avere una quota insufficiente. Per ulteriori informazioni sui limiti di quota per questi servizi, consulta Quota Pub/Sub o Quota BigQuery.

Se il tuo job genera un numero elevato di errori 429 (Rate Limit Exceeded), la quota potrebbe essere insufficiente. Per verificare la presenza di errori, prova i seguenti passaggi:

  1. Vai alla console Google Cloud.
  2. Nel riquadro di navigazione, fai clic su API e servizi.
  3. Nel menu, fai clic su Raccolta.
  4. Utilizza la casella di ricerca per cercare Pub/Sub.
  5. Fai clic su API Cloud Pub/Sub.
  6. Fai clic su Gestisci.
  7. Nel grafico Traffico per codice di risposta, cerca i codici di errore client (4xx).

Puoi anche utilizzare Metrics Explorer per controllare l'utilizzo della quota. Se la pipeline utilizza un'origine o una destinazione BigQuery, per risolvere i problemi relativi alle quote, utilizza le metriche dell'API BigQuery Storage. Ad esempio, per creare un grafico che mostri il numero di connessioni simultanee di BigQuery, segui questi passaggi:

  1. Nella console Google Cloud, seleziona Monitoring:

    Vai a Monitoring

  2. Nel riquadro di navigazione, seleziona Esplora metriche.

  3. Nel riquadro Seleziona una metrica, per Metrica, filtra su Progetto BigQuery > Scrittura > Conteggio connessioni simultanee.

Per istruzioni su come visualizzare le metriche di Pub/Sub, consulta Monitorare l'utilizzo della quota in "Monitorare Pub/Sub in Cloud Monitoring". Per istruzioni su come visualizzare le metriche BigQuery, consulta Visualizzare l'utilizzo e i limiti della quota in "Creare dashboard, grafici e avvisi".

Batch

Se il job batch è lento o bloccato, utilizza la scheda Dettagli esecuzione per trovare ulteriori informazioni sul job e identificare la fase o il worker che sta causando un collo di bottiglia.

Identificare gli elementi in ritardo

Un elemento in ritardo è un elemento di lavoro lento rispetto ad altri elementi di lavoro nella fase. Per informazioni su come identificare e correggere i job in ritardo, consulta Risolvere i problemi relativi ai job in ritardo nei job batch.

Identifica le fasi lente o bloccate

Per identificare le fasi lente o bloccate, utilizza la visualizzazione Avanzamento fase. Le barre più lunghe indicano che la fase richiede più tempo. Utilizza questa visualizzazione per identificare le fasi più lente della pipeline.

Una volta individuata la fase di collasso, puoi procedere nel seguente modo:

  • Identifica il worker in ritardo all'interno di questa fase.
  • Se non ci sono attività in ritardo, identifica il passaggio più lento utilizzando il riquadro Informazioni sulla fase. Utilizza queste informazioni per identificare i candidati per l'ottimizzazione del codice utente.
  • Per trovare i colli di bottiglia del parallelismo, utilizza le metriche di monitoraggio di Dataflow.

Identificare un worker in ritardo

Per identificare un worker in ritardo per una fase specifica, utilizza la visualizzazione Avanzamento dei worker. Questa visualizzazione mostra se tutti i worker stanno elaborando il lavoro fino alla fine della fase o se un singolo worker è bloccato su un'attività in ritardo. Se trovi un utente in ritardo, procedi nel seguente modo:

Strumenti per il debug

Quando una pipeline è lenta o bloccata, i seguenti strumenti possono aiutarti a diagnosticare il problema.

  • Per correlare gli incidenti e identificare i colli di bottiglia, utilizza Cloud Monitoring per Dataflow.
  • Per monitorare le prestazioni della pipeline, utilizza Cloud Profiler.
  • Alcuni trasformamenti sono più adatti di altri alle pipeline ad alto volume. I messaggi log possono identificare una trasformazione dell'utente bloccata nelle pipeline batch o in streaming.
  • Per scoprire di più su un job bloccato, utilizza Metriche dei job Dataflow. Il seguente elenco include metriche utili:
    • La metrica Byte in coda (backlog_bytes) misura la quantità di input non elaborato in byte per fase. Utilizza questa metrica per trovare un passaggio unito senza throughput. Analogamente, la metrica Elementi in coda (backlog_elements) misura il numero di elementi di input non elaborati per una fase.
    • La metrica Chiavi di parallelismo di elaborazione (processing_parallelism_keys) misura il numero di chiavi di elaborazione parallela per una determinata fase della pipeline negli ultimi cinque minuti. Utilizza questa metrica per eseguire indagini nei seguenti modi:
      • Restringi il problema a fasi specifiche e conferma gli avvisi relativi alle hotkey, ad esempio A hot key ... was detected.
      • Individua i colli di bottiglia del throughput causati da un parallelismo insufficiente. Questi colli di bottiglia possono causare pipeline lente o bloccate.
    • La metrica Ritardo sistema (system_lag) e la metrica Ritardo sistema per fase (per_stage_system_lag) misurano il tempo massimo di elaborazione o di attesa di un elemento di dati. Utilizza queste metriche per identificare fasi e colli di bottiglia inefficienti delle origini dati.

Per altre metriche non incluse nell'interfaccia web di monitoraggio di Dataflow, consulta l'elenco completo delle metriche di Dataflow in Metriche di Google Cloud.