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:

• La pipeline non legge i dati dall'origine. Ad esempio, Pub/Sub ha un backlog in crescita.
• La pipeline non scrive dati nel sink.
• La metrica di aggiornamento dei dati è in aumento.
• La metrica della latenza del sistema è in aumento.

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.

• Se l'eccezione riguarda il codice utente, esegui il debug e correggi il problema nel codice o nei dati.
• Per evitare che errori imprevisti blocchino la pipeline, implementa una coda di messaggi inutilizzati. Per un esempio di implementazione, consulta Pattern BigQuery nella documentazione di Apache Beam.
• Se l'eccezione è un errore di memoria insufficiente (OOM), consulta Risolvere gli errori di memoria insufficiente di Dataflow.
• Per altre eccezioni, consulta Risolvere gli errori di Dataflow.

Identificare i lavoratori non conformi

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

• Verifica la pressione della memoria utilizzando le metriche di utilizzo della memoria e cercando errori di esaurimento della memoria nei log dei worker. Per ulteriori informazioni, consulta Risolvere gli errori di esaurimento della memoria di Dataflow.
• Se utilizzi Streaming Engine, utilizza le metriche di persistenza per identificare i colli di bottiglia con le operazioni di input/output (IOPS) del disco.
• Controlla la presenza di altri errori nei log del worker. Per ulteriori informazioni, consulta Utilizzare i log della pipeline e Risolvere i problemi di Dataflow.

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 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.
  • Per raccogliere ulteriori informazioni, utilizza le metriche di input e output fornite da Dataflow.
  • Se utilizzi Kafka, controlla il numero di partizioni Kafka. Per ulteriori informazioni, consulta la documentazione di Apache Kafka.
  • Se utilizzi un sink BigQuery, attiva lo sharding automatico per migliorare il parallelismo. Per saperne di più, consulta 3 volte il throughput di Dataflow con lo sharding automatico per BigQuery.

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:

• Modifica la chiave dei 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, 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 worker 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:

• Visualizza i file di log del worker. Per ulteriori informazioni, consulta Monitorare e visualizzare i log della pipeline.
• Visualizza le metriche di utilizzo della CPU e i dettagli relativi all'avanzamento dei worker per i worker in ritardo. Se noti un utilizzo della CPU insolitamente elevato o ridotto, nei file di log del relativo worker, cerca i seguenti problemi:
  • A hot key ... was detected
  • Processing stuck ... Operation ongoing

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