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.

Identifica la causa principale

  1. Controlla le metriche relative all'aggiornamento dei dati e ai byte in coda.

    • Se entrambe le metriche sono in aumento in modo monotono, significa che la pipeline è bloccata e non avanza.
    • Se l'aggiornamento dei dati è in aumento, ma i byte in coda rimangono normali, significa che uno o più elementi di lavoro sono bloccati nella pipeline.

    Cerca le fasi in cui queste metriche sono in aumento per identificare eventuali fasi con problemi e le operazioni eseguite in quella fase.

  2. Controlla il grafico di elaborazione in parallelo per vedere se una fase è bloccata a causa di un parallelismo ridotto. Consulta la sezione Risolvere i problemi relativi al parallelismo.

  3. Controlla i log dei job per verificare la presenza di problemi come limiti di quota, problemi di esaurimento delle scorte o esaurimento degli indirizzi IP.

  4. Controlla i log dei worker per individuare avvisi ed errori.

    • Se i log del worker contengono errori, visualizza la traccia dello stack. Verifica se l'errore è causato da un bug nel codice.
    • Cerca gli errori di Dataflow. Consulta Risolvere gli errori di Dataflow.
    • Cerca gli errori che indicano che il job ha superato un limite, ad esempio le dimensioni massime del messaggio Pub/Sub.
    • Cerca gli errori di esaurimento della memoria, che possono causare il blocco della pipeline. Se vedi errori di memoria insufficiente, segui i passaggi descritti in Risolvere gli errori di memoria insufficiente di Dataflow.
    • Per identificare un passaggio lento o bloccato, controlla i messaggi Operation ongoing nei log del worker. Visualizza la traccia dello stack per vedere dove il passaggio sta impiegando tempo. Per ulteriori informazioni, vedi Elaborazione bloccata o operazione in corso.

  5. Se un elemento di lavoro è bloccato su un worker specifico, riavvia la VM del worker.

  6. Se non utilizzi Streaming Engine, controlla i log dello shuffler per verificare la presenza di avvisi ed errori. Se viene visualizzato un errore di timeout RPC sulla porta 12345 o 12346, è possibile che nel job manchi una regola firewall. Consulta Regole firewall per Dataflow.

  7. Controlla la presenza di tasti di scelta rapida.

  8. Se Runner v2 è abilitato, controlla se sono presenti errori nei log del cablaggio. Per ulteriori informazioni, consulta Risolvere i problemi di Runner v2.

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 relativi al 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 tuo 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 la sezione 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.

Verifica la presenza di tasti di scelta rapida utilizzando il seguente filtro di log:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.line:"hot_key_logger"

Sostituisci JOB_ID con l'ID del tuo job.

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 PCollectionsnon limitati di alto volume, 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 avere una quota sufficiente per l'origine e la destinazione. Ad esempio, se la pipeline legge input da Pub/Sub o BigQuery, la quota del tuo Google Cloud progetto potrebbe non essere sufficiente. 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 Monitoraggio:

    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 di 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.

Identifica la causa principale

  1. Controlla se il job riscontra problemi durante l'avvio del worker. Per ulteriori informazioni, consulta la sezione Errore durante la sincronizzazione del pod.

    Per verificare che il job abbia iniziato a elaborare i dati, cerca la seguente voce nel log job-message:

    All workers have finished the startup processes and began to receive work requests

  2. Per confrontare le prestazioni di job diversi, assicurati che il volume dei dati di input, la configurazione dei worker, il comportamento della scalabilità automatica e le impostazioni di Dataflow Shuffle siano gli stessi.

  3. Controlla i log job-message per verificare la presenza di problemi come limiti di quota, problemi di esaurimento delle scorte o esaurimento degli indirizzi IP.

  4. Nella scheda Dettagli esecuzione, confronta l'avanzamento della fase per identificare le fasi che hanno richiesto più tempo.

  5. Cerca eventuali elementi in sospeso nel job. Per ulteriori informazioni, consulta la sezione Risolvere i problemi relativi ai job in batch in ritardo.

  6. Controlla le metriche relative a velocità effettiva, CPU e utilizzo della memoria.

  7. Controlla i log dei worker per verificare la presenza di avvisi e errori.

  8. Controlla la presenza di tasti di scelta rapida.

  9. Se non utilizzi Dataflow Shuffle, controlla i log dello shuffler per verificare la presenza di avvisi e errori durante l'operazione di ordinamento casuale. Se viene visualizzato un errore di timeout RPC sulla porta 12345 o 12346, è possibile che nel job manchi una regola firewall. Consulta Regole firewall per Dataflow.

  10. Se Runner v2 è abilitato, controlla la presenza di errori nei log del harness. Per ulteriori informazioni, consulta Risolvere i problemi di Runner v2.

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 sono presenti utenti 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 alle pipeline ad alto volume rispetto ad altri. 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 del backlog (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 nelle origini dati.

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