Risolvere i problemi relativi a job lenti o bloccati

Questa pagina spiega come risolvere i problemi relativi alle cause comuni di lentezza o blocco dei job batch e di streaming Dataflow.

Streaming

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

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

Identificare la causa principale

  1. Controlla le metriche Aggiornamento dei dati e Byte backlog.

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

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

  2. Controlla il grafico dell'elaborazione parallela per verificare se una fase è bloccata a causa di un parallelismo eccessivo o insufficiente. Consulta la sezione Risolvere i problemi di parallelismo.

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

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

    • Se i log del worker contengono errori, visualizza la analisi dello stack. Verifica se l'errore è causato da un bug nel codice.
    • Cerca gli errori di Dataflow. Consulta la sezione Risolvere gli errori di Dataflow.
    • Cerca errori che indicano che il job ha superato un limite, ad esempio le dimensioni massime del messaggio Pub/Sub.
    • Cerca errori di esaurimento della memoria, che possono causare il blocco di una pipeline. Se visualizzi 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 log del worker per i messaggi Operation ongoing. Visualizza l'analisi dello stack per vedere dove il passaggio trascorre il 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 worker.

  6. Se non utilizzi Streaming Engine, controlla i log di Shuffler per avvisi ed errori. Se visualizzi 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 la presenza di errori nei log dell'imbracatura. Per ulteriori informazioni, consulta Risoluzione dei problemi di Runner v2.

Esamina gli errori ripetuti

In un job di streaming, alcuni errori vengono riprovati all'infinito. Questi tentativi impediscono l'avanzamento della pipeline. Per identificare errori ripetuti, controlla i log del worker per le eccezioni.

Identificare i worker non integri

Se i worker che elaborano il job di streaming non sono integri, il job potrebbe essere lento o bloccato. Per identificare i worker non integri:

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, vedi Risolvere i problemi relativi agli elementi in ritardo nei job di streaming.

Risolvere i problemi di parallelismo

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 unita 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 Kafka.
  • La chiave è definita esplicitamente dalla logica di aggregazione nella pipeline, ad esempio GroupByKey.

In Dataflow, i thread worker sono responsabili della gestione dell'elaborazione dei bundle di lavoro (messaggi) per una chiave. Il numero di thread disponibili per elaborare le chiavi del job è pari a num_of_workers * threads_per_worker. Il numero di thread per worker è determinato in base all'SDK (Java, Python o Go) e al tipo di job (batch o streaming).

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

Se la pipeline utilizza un numero molto elevato di chiavi per una determinata fase, può limitare la velocità effettiva della fase e accumulare backlog nelle fasi precedenti, perché c'è un sovraccarico per chiave. Le spese generali potrebbero includere la comunicazione del backend con i worker, le RPC esterne a un sink come BigQuery e altre elaborazioni. Ad esempio, se l'elaborazione di una chiave con un messaggio richiede 100 ms, potrebbe essere necessario anche circa 100 ms per elaborare 1000 messaggi nel bundle di chiavi.

Identificare le fasi con parallelismo basso

Per identificare se la lentezza della pipeline è causata da un basso parallelismo, visualizza le metriche di utilizzo della CPU. Se l'utilizzo della CPU è basso, ma distribuito uniformemente tra i worker, il job potrebbe avere un parallelismo insufficiente. Se il job utilizza Streaming Engine, per verificare se una fase ha un parallelismo basso, nella scheda Metriche job, visualizza le metriche di parallelismo. Per risolvere il problema:

Identificare le fasi con parallelismo elevato

Una combinazione di bassa latenza di sistema, crescente frequenza di aggiornamento dei dati e aumento del backlog e delle CPU dei worker sottoutilizzate suggerisce che la pipeline viene limitata a causa di un numero elevato di chiavi. Controlla il grafico Elaborazione parallela per identificare le fasi con un numero elevato di chiavi.

Trasformazioni come Reshuffle possono generare milioni di chiavi se non specifichi esplicitamente withNumBuckets. Un numero elevato di chiavi può portare alla creazione di numerosi bundle di lavoro più piccoli, ognuno dei quali richiede un thread worker dedicato per l'elaborazione. Poiché i thread worker disponibili sono limitati, può verificarsi un backlog significativo di chiavi di elaborazione, causando ritardi in quanto attendono le risorse. Di conseguenza, i thread di lavoro non vengono utilizzati in modo efficiente.

Ti consigliamo di limitare il numero di chiavi impostando l'opzione withNumBuckets nella trasformazione Reshuffle. Il valore non deve superare il numero totale di thread in tutti i worker. Le chiavi di (threads_per_worker * max_workers) targeting nella pipeline potrebbero non essere ottimali. A volte sono possibili meno chiavi e bundle più grandi, che vengono elaborati in modo più efficiente da Dataflow grazie all'utilizzo di un numero inferiore di worker. Un numero inferiore di chiavi crea bundle di lavoro più grandi, che utilizzano in modo efficiente i thread di worker e aumentano il throughput dello stage.

Se nella pipeline sono presenti più passaggi Reshuffle, dividi il numero totale di thread per il conteggio dei passaggi Reshuffle per calcolare withNumBuckets.

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 tasto di scelta rapida. Una hot key è una chiave che ha molti più elementi da elaborare rispetto alle altre chiavi.

Controlla le scorciatoie da tastiera utilizzando il seguente filtro dei 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:

  • Riassegna le chiavi ai tuoi dati. Per generare nuove coppie chiave-valore, applica una trasformazione ParDo. Per saperne di più, consulta la pagina di trasformazione ParDo Java o la pagina di trasformazione ParDo Python nella documentazione di Apache Beam.
  • Utilizza .withFanout nelle trasformazioni combinate. Per maggiori 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 PCollections senza limiti di volume elevato, ti consigliamo di procedere nel seguente modo:
    • Utilizza Combine.Globally.withFanout anziché Combine.Globally.
    • Utilizza Combine.PerKey.withHotKeyFanout anziché Count.PerKey.

Controllare se la quota è insufficiente

Assicurati di avere una quota sufficiente per l'origine e la destinazione. Ad esempio, se la pipeline legge l'input da Pub/Sub o BigQuery, il progetto potrebbe non disporre di una quota sufficiente. Google Cloud Per saperne di più 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), potrebbe avere una quota insufficiente. Per verificare la presenza di errori, prova i seguenti passaggi:

  1. Vai alla Google Cloud console.
  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 un sink BigQuery, per risolvere i problemi relativi alla quota, utilizza le metriche dell'API BigQuery Storage. Ad esempio, per creare un grafico che mostri il conteggio delle connessioni simultanee BigQuery, segui questi passaggi:

  1. Nella console Google Cloud , seleziona Monitoring:

    Vai a Monitoring

  2. Nel riquadro di navigazione, seleziona Metrics Explorer.

  3. 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 di esecuzione per trovare maggiori informazioni sul job e per identificare la fase o il worker che sta causando un collo di bottiglia.

Identificare la causa principale

  1. Controlla se il job presenta problemi durante l'avvio del worker. Per saperne di più, vedi Errore di sincronizzazione del pod.

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

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

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

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

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

  5. Cerca eventuali elementi rimanenti nel job. Per saperne di più, vedi Risoluzione dei problemi relativi ai processi batch in ritardo.

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

  7. Controlla la presenza di avvisi ed errori nei log dei worker.

  8. Controlla la presenza di tasti di scelta rapida.

  9. Se non utilizzi Dataflow Shuffle, controlla i log di Shuffler per avvisi ed errori durante l'operazione di shuffle. Se visualizzi 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 i log della briglia per verificare la presenza di errori. 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 ritardatari, vedi Risolvere i problemi relativi ai ritardatari nei job batch.

Identificare 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 del collo di bottiglia, puoi procedere nel seguente modo:

Identificare un lavoratore in ritardo

Per identificare un worker in ritardo per una fase specifica, utilizza la visualizzazione Avanzamento worker. Questa visualizzazione mostra se tutti i worker elaborano il lavoro fino alla fine della fase o se un singolo worker è bloccato su un'attività in ritardo. Se trovi un lavoratore 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.
  • Alcune trasformazioni sono più adatte alle pipeline ad alto volume rispetto ad altre. I messaggi di log possono identificare una trasformazione dell'utente bloccata nelle pipeline batch o di streaming.
  • Per saperne di più su un job bloccato, utilizza le metriche dei job Dataflow. Il seguente elenco include metriche utili:
    • La metrica Byte 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 throughput. Allo stesso modo, la metrica Elementi backlog (backlog_elements) misura il numero di elementi di input non elaborati per una fase.
    • La metrica Chiavi di parallelismo dell'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 ai tasti di scelta rapida, ad esempio A hot key ... was detected.
      • Trova 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 per cui un elemento di dati è stato elaborato o è in attesa di elaborazione. Utilizza queste metriche per identificare le fasi inefficienti e i colli di bottiglia delle origini dati.

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