Risolvere i problemi relativi a job lenti o bloccati

Questa pagina spiega come risolvere i problemi più comuni di job Dataflow lento o bloccato in modalità flusso e batch.

Flussi di dati

Se noti i seguenti sintomi, il job di inserimento di flussi di Dataflow potrebbe essere eseguito lentamente o bloccato:

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

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

Esaminare gli errori ripetuti

In un job di inserimento flussi, alcuni errori vengono riprovati a tempo indeterminato. Questi nuovi tentativi impediscono l'avanzamento della pipeline. Per identificare gli errori ripetuti, controlla la presenza di eccezioni nei log del worker.

Se l'eccezione riguarda il codice utente, esegui il debug e risolvi il problema nel codice o nei dati.
Per evitare che la pipeline blocchi la pipeline in modo imprevisto, implementa una coda messaggi non recapitabili. Per un'implementazione di esempio, consulta Pattern BigQuery nella documentazione di Apache Beam.
Se l'eccezione è un errore di esaurimento della memoria (OOM), consulta Risolvere i problemi di esaurimento della memoria di Dataflow.
Per altre eccezioni, consulta Risoluzione degli errori di Dataflow.

Identificare i lavoratori insalubri

Se i worker che elaborano il job di elaborazione in modalità flusso non sono integri, il job potrebbe essere lento o essere bloccato. Per identificare i lavoratori in stato non integro:

Verifica la pressione della memoria utilizzando le metriche di utilizzo della memoria e cercando gli errori di memoria insufficiente nei log del worker. Per ulteriori informazioni, consulta Risolvere i problemi di esaurimento della memoria di Dataflow.
Se usi Streaming Engine, usa le metriche sulla 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 gli articoli Utilizzare i log di pipeline e Risolvere gli errori di Dataflow.

Identifica gli elementi in ritardo

Un elemento in ritardo è un elemento di lavoro lento rispetto ad altri elementi 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 flussi di dati.

Risolvere i problemi di parallelismo insufficiente

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

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

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

Identificare le fasi con basso parallelismo

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

Nella pagina Informazioni sul job della console Google Cloud, utilizza la scheda Scalabilità automatica per vedere se si verificano problemi di scale up del job. Se il problema è la scalabilità automatica, consulta Risoluzione dei problemi relativi alla scalabilità automatica di Dataflow.
Utilizza il grafico del job per controllare i passaggi nella fase. Se lo stage legge da una fonte o sta scrivendo in un sink, consulta la documentazione relativa al servizio dell'origine o del sink. Utilizza la documentazione per determinare se il servizio è configurato per una scalabilità sufficiente.
- Per raccogliere ulteriori informazioni, utilizza le metriche di input e di 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, abilita lo sharding automatico per migliorare il parallelismo. Per ulteriori informazioni, consulta Velocità effettiva di Dataflow 3x con shard automatico per BigQuery.

Verifica 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 una chiave di accesso rapida. Una chiave di scelta rapida è una chiave che ha molti più elementi da elaborare rispetto ad altre chiavi. Per risolvere il problema, esegui uno o più dei seguenti passaggi:

Ridenominazione dei dati. Per generare nuove coppie chiave-valore, applica una trasformazione ParDo. Per ulteriori informazioni, consulta la pagina sulla trasformazione ParDo Java o la pagina sulla trasformazione ParDo in Python nella documentazione di Apache Beam.
Utilizza .withFanout nelle trasformazioni di tipo combina. 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 volumi elevati PCollections, ti consigliamo di procedere come segue:
- Usa Combine.Globally.withFanout anziché Combine.Globally.
- Usa Combine.PerKey.withHotKeyFanout anziché Count.PerKey.

Verifica la presenza di una quota insufficiente

Assicurati di disporre di una quota sufficiente per l'origine e il sink. Ad esempio, se la pipeline legge l'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 di BigQuery.

Se il job genera un numero elevato di 429 (Rate Limit Exceeded) errori, potrebbe avere una quota insufficiente. Per verificare la presenza di errori, prova a procedere nel seguente modo:

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

Puoi anche utilizzare Metrics Explorer per controllare l'utilizzo della quota. Se la pipeline utilizza un'origine o un sink BigQuery, per risolvere i problemi di quota 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:

Nella console Google Cloud, seleziona Monitoring:

Vai a Monitoring
Nel riquadro di navigazione, seleziona Metrics Explorer.
Nel riquadro Seleziona una metrica, per Metrica, filtra in base a Progetto BigQuery > Scrittura > Conteggio connessioni simultanee.

Per istruzioni sulla visualizzazione delle metriche Pub/Sub, consulta Monitorare l'utilizzo della quota in "Monitorare Pub/Sub in Cloud Monitoring". Per istruzioni sulla visualizzazione delle metriche BigQuery, consulta Visualizzare l'utilizzo e i limiti delle quote 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 causa un collo di bottiglia.

Identifica gli elementi in ritardo

Un elemento in ritardo è un elemento di lavoro lento rispetto ad altri elementi nella fase. Per informazioni sull'identificazione e sulla correzione degli elementi in ritardo, consulta Risolvere i problemi relativi agli elementi in ritardo nei job batch.

Identificare le fasi lente o bloccate

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

Dopo aver individuato la fase del collo di bottiglia, puoi procedere nel seguente modo:

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

Identifica un lavoratore in ritardo

Per identificare un worker in ritardo per una fase specifica, utilizza la visualizzazione Avanzamento del 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 lavoratore in ritardo, segui questa procedura:

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

Strumenti per il debug

Se hai 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.
Alcune trasformazioni sono più adatte di altre a pipeline con volumi elevati. I messaggi di log possono identificare una trasformazione utente bloccata nelle pipeline in modalità batch o flusso.
Per scoprire di più su un job bloccato, utilizza le metriche dei job di Dataflow. Il seguente elenco include metriche utili:
- La metrica Byte di backlog (backlog_bytes) misura la quantità di input non elaborati in byte per fase. Utilizza questa metrica per trovare un passaggio unito che non ha velocità effettiva. Allo stesso modo, la metrica degli elementi del backlog (backlog_elements) misura il numero di elementi di input non elaborati per una fase.
- La metrica Elaborazione delle chiavi di parallelismo (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 effettuare accertamenti nei seguenti modi:
  - Restringi il problema a fasi specifiche e conferma gli avvisi dei tasti di scelta rapida, ad esempio A hot key ... was detected.
  - Individua i colli di bottiglia della velocità effettiva causati da un parallelismo insufficiente. Questi colli di bottiglia possono causare pipeline lente o bloccate.
- La metrica Ritardo di sistema (system_lag) e la metrica Ritardo di sistema per fase (per_stage_system_lag) misurano il tempo massimo durante il quale un elemento di dati è stato elaborato o è in attesa di elaborazione. Utilizza queste metriche per identificare fasi e colli di bottiglia inefficienti dalle origini dati.

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