Si verifica un collo di bottiglia quando un passaggio, una fase o un worker rallenta il job complessivo. I colli di bottiglia possono portare a worker inattivi e a una maggiore latenza.
Se Dataflow rileva un collo di bottiglia, nel grafico del job viene visualizzato un avviso e il riquadro Informazioni sul passaggio elenca il tipo di collo di bottiglia e la causa, se nota. Dataflow esporta anche le informazioni sul rilevamento dei colli di bottiglia in una metrica di Monitoring, che presenta i dati come una serie temporale. In questo modo, puoi visualizzare i colli di bottiglia nel tempo o in passato.
Informazioni sui colli di bottiglia
Quando Dataflow esegue una pipeline di flusso, il job è costituito da una
serie di componenti, come gli
shuffle di flusso,
thread di elaborazione funzione definita dall'utente (DoFn) e
checkpointing dello stato persistente. Per facilitare il flusso di dati, Dataflow utilizza le code per collegare questi componenti. I dati vengono inviati da monte a valle.
In molte pipeline, la capacità di velocità effettiva complessiva è vincolata da un singolo componente, creando un collo di bottiglia nella pipeline. La velocità con cui i dati possono spostarsi attraverso un collo di bottiglia limita la velocità con cui la pipeline può accettare ed elaborare i dati di input.
Ad esempio, considera una pipeline in cui l'elaborazione DoFn avviene a valle di uno shuffle di flusso. Una coda tra di loro memorizza nel buffer i dati sottoposti a shuffle ma non elaborati. Se l'elaborazione DoFn non riesce a utilizzare i dati con la stessa velocità con cui lo shuffle di flusso li produce, la coda aumenta. Un collo di bottiglia prolungato può far sì che la coda raggiunga la sua capacità. A questo punto, lo shuffle viene messo in pausa e il backlog si propaga a monte. Anche le code più a monte accumulano backlog, causando infine un rallentamento che si estende all'origine dati, il che significa che l'intera pipeline non riesce a tenere il passo con l'input.
Quando si verifica un collo di bottiglia, una parte sostanziale della pipeline potrebbe sembrare non integra, anche se un singolo punto della pipeline sta causando il backlog. Questo comportamento può rendere difficile il debug dei colli di bottiglia. L'obiettivo del rilevamento dei colli di bottiglia è identificare la posizione e la causa esatte, eliminando le congetture, in modo da poter risolvere la causa principale.
Dataflow rileva un collo di bottiglia quando un ritardo supera la soglia di cinque minuti. Se il ritardo non supera questa soglia, Dataflow non rileva un collo di bottiglia.
Il rilevamento dei colli di bottiglia non richiede sempre un intervento e dipende dal tuo caso d'uso. Una pipeline può funzionare normalmente con ritardi temporanei superiori a cinque minuti. Se questa situazione è accettabile per il tuo caso d'uso, potresti non dover risolvere i colli di bottiglia indicati.
Tipi di colli di bottiglia
Quando Dataflow rileva un collo di bottiglia, l'interfaccia di monitoraggio indica la gravità del problema. I colli di bottiglia rientrano nelle seguenti categorie:
- L'elaborazione è bloccata e non procede
- L'avanzamento della pipeline è completamente interrotto in questo passaggio.
- L'elaborazione è in corso, ma è in ritardo.
- La pipeline non riesce a elaborare i dati in entrata con la stessa velocità con cui arrivano. Di conseguenza, il backlog è in aumento.
- L'elaborazione è in corso, ma il backlog è stabile
- La pipeline sta facendo progressi e la velocità di elaborazione è paragonabile alla velocità di input. L'elaborazione è abbastanza veloce da non far aumentare il backlog, ma il backlog accumulato non diminuisce in modo significativo.
- L'elaborazione è in corso e sta recuperando da un backlog
- Il backlog è in diminuzione, ma il collo di bottiglia attuale impedisce alla pipeline di recuperare più velocemente. Se avvii una pipeline con un backlog, questo stato potrebbe essere normale e non richiedere alcun intervento. Monitora l'avanzamento per verificare se il backlog continua a diminuire.
Cause dei colli di bottiglia
In questa sezione sono elencate le cause dei colli di bottiglia che possono essere rilevate. Utilizza queste informazioni per risolvere il problema. In alcuni casi, potrebbero essere presenti più cause, che potrebbero essere correlate. Ad esempio, se il provisioning dei worker è insufficiente, l'utilizzo della vCPU potrebbe essere elevato. Un utilizzo elevato della vCPU può rallentare le operazioni, il che a sua volta può creare un ritardo elevato nella coda. L'analisi delle cause probabili potrebbe visualizzare tutte queste cause come cause del collo di bottiglia.
- Operazioni con tempi di elaborazione lunghi
Alcune operazioni in questo calcolo hanno un tempo di elaborazione lungo. Ciò si verifica ogni volta che un bundle di input viene inviato al worker che esegue
DoFne trascorre un tempo significativo senza che siano disponibili risultati.Questo è il risultato più frequente di una singola operazione a lunga esecuzione nel codice utente. Altri problemi possono manifestarsi come operazioni con tempi di elaborazione lunghi. Ad esempio, gli errori generati e riprovati all'interno di
DoFn, i tentativi per periodi di tempo lunghi o gli arresti anomali dell'harness del worker dovuti a fattori come gli errori di memoria insufficiente possono causare questi tempi di elaborazione lunghi.Se il calcolo interessato si trova nel codice utente, cerca modi per ottimizzare il codice o limitare il tempo di esecuzione. Per facilitare il debug, i log dei worker mostrano le tracce dello stack per tutte le operazioni bloccate per più di 5 minuti.
- Commit della chiave troppo grande
Consulta l'articolo Eccezione di commit della chiave troppo grande.
- Tempi di elaborazione lunghi per tutte le operazioni
Le operazioni in questo calcolo richiedono costantemente molto tempo, il che suggerisce un problema all'interno di
DoFnfornito dall'utente.Questa causa è diversa da Operazioni con tempi di elaborazione lunghi; mentre quest'ultima influisce su alcune operazioni, questa causa indica che tutte le operazioni in questo calcolo sono interessate.
Controlla i log dei worker per verificare la presenza di errori, eccezioni o tracce dello stack che indicano thread lenti o bloccati. Se utilizzi l'SDK Apache Beam per Python e se le operazioni sono intrinsecamente di lunga durata per progettazione (ad esempio, chiamate API esterne lente o I/O a latenza elevata), valuta la possibilità di utilizzare un DoFn asincrono. Questa funzionalità può migliorare la velocità effettiva impedendo che l'elaborazione venga bloccata da queste attività di lunga durata.
- Lettura lenta dello stato persistente
Il calcolo impiega una quantità significativa di tempo per leggere lo stato persistente nell'ambito dell'esecuzione di
DoFn. Questo potrebbe essere il risultato di uno stato persistente eccessivamente grande o di troppe letture. Valuta la possibilità di ridurre le dimensioni dello stato persistente o la frequenza delle letture. Ottimizza i pattern di accesso allo stato combinando più operazioni di lettura dello stato o utilizzando lo stato della mappa anziché lo stato del valore, se appropriato. Potrebbe trattarsi anche di un problema temporaneo dovuto alla lentezza dello stato persistente sottostante.- Scrittura lenta dello stato persistente
Il calcolo impiega una quantità significativa di tempo per scrivere lo stato persistente durante il commit dei risultati dell'elaborazione. Questo potrebbe essere il risultato di uno stato persistente eccessivamente grande. Valuta la possibilità di ridurre le dimensioni dello stato persistente. Ottimizza i pattern di accesso allo stato combinando più operazioni di scrittura dello stato, se appropriato. Potrebbe trattarsi anche di un problema temporaneo dovuto alla lentezza dello stato persistente sottostante.
- Commit rifiutato
L'elaborazione dei dati non può essere eseguita nello stato persistente perché non è valida. Di solito, questo problema è dovuto al superamento di uno dei limiti operativi limits. Controlla i log per maggiori dettagli o contatta l'assistenza.
- Numero insufficiente di partizioni dell'origine Apache Kafka
Il calcolo dell'origine Apache Kafka ha un numero insufficiente di partizioni. Per risolvere il problema, prova quanto segue:
- Aumenta il numero di partizioni Kafka.
- Includi la ridistribuzione utilizzando
.withRedistribute()quando configuri la lettura di I/O Kafka per parallelizzare i dati in modo più efficiente. Includi.withRedistributeNumKeys(N)doveN > partitionsper fornire un limite superiore al numero totale di chiavi. Un numero limitato di chiavi garantisce l'efficienza tramite il raggruppamento dei record. - Per ridurre al minimo il costo dello shuffle di ridistribuzione, utilizza
.withOffsetDeduplication(). Questa modalità riduce al minimo la quantità di dati che devono essere resi persistenti nell'ambito dello shuffle, pur fornendo un'elaborazione exactly-once.
Per ulteriori informazioni, consulta Parallelismo nella pagina Leggere da Apache Kafka a Dataflow.
- Volume elevato di stato persistente dell'origine Apache Kafka
Il calcolo dell'origine Apache Kafka sta ridistribuendo un volume elevato di dati che potrebbe comportare costi e latenza elevati. Per risolvere il problema, prova quanto segue:
- Se per la pipeline è richiesta l'elaborazione exactly-once, riduci al minimo il costo dello shuffle di ridistribuzione utilizzando la modalità di deduplicazione dell'offset. Questa modalità riduce al minimo la quantità di dati che devono essere resi persistenti nell'ambito dello shuffle, pur fornendo un'elaborazione exactly-once.
- Se per la pipeline è sufficiente l'elaborazione at-least-once, è possibile attivare la configurazione Consenti duplicati.
Per ulteriori informazioni, consulta Leggere da Apache Kafka a Dataflow.
- Parallelismo origine insufficiente
Un calcolo dell'origine ha un parallelismo insufficiente. Se possibile, aumenta la parallelizzazione all'interno dell'origine. Se non puoi aumentare la parallelizzazione e il job utilizza la modalità at-least-once, prova ad aggiungere una trasformazione
Redistributealla pipeline.- Chiavi utilizzate di frequente o parallelismo insufficiente delle chiavi
Il job ha chiavi utilizzate di frequente o un parallelismo insufficiente delle chiavi.
Per ogni chiave di sharding, Dataflow elabora i messaggi in serie. Mentre Dataflow elabora un batch di messaggi per una determinata chiave, gli altri messaggi in entrata per quella chiave vengono messi in coda fino al completamento del batch corrente.
Se Dataflow non riesce a elaborare un numero sufficiente di chiavi distinte in parallelo, può causare un collo di bottiglia. Ad esempio, i dati potrebbero avere un numero troppo basso di chiavi distinte o alcune chiavi potrebbero essere sovra rappresentate nei dati ("chiavi utilizzate di frequente"). Per risolvere il problema, modifica la logica della pipeline per ridistribuire i dati. Ad esempio, aggiungi un suffisso casuale alle chiavi di raggruppamento per suddividere le chiavi utilizzate di frequente e aggregare i risultati in un passaggio successivo. Per maggiori dettagli, consulta Risolvere i problemi relativi alle chiavi utilizzate di frequente.
- Provisioning insufficiente delle vCPU
Il job non ha un numero sufficiente di vCPU worker. Questa situazione si verifica quando il job è già scalato al massimo, l'utilizzo della vCPU è elevato e c'è ancora un backlog. Potresti dover aumentare il numero massimo di worker di cui è stato eseguito il provisioning per questo job. Ad esempio, puoi aumentare questo numero con un aggiornamento all'intervallo di scalabilità automatica. In alternativa, cerca modi per ridurre l'utilizzo della vCPU modificando il codice della pipeline o il workload. Puoi utilizzare Cloud Profiler per cercare opportunità di ottimizzazione.
- Utilizzo elevato della vCPU, in attesa di scale up
Il job ha un utilizzo elevato della vCPU, ma c'è spazio per lo scale up. È probabile che questa condizione sia temporanea fino a quando non sarà possibile eseguire lo scale up. Puoi monitorare la scalabilità automatica per visualizzare le decisioni di scalabilità automatica. Se questa condizione persiste a lungo o si verifica di frequente, potrebbe essere necessario modificare la configurazione della scalabilità automatica impostando un suggerimento di utilizzo dei worker diverso per consentire al job di eseguire lo scale up in modo più proattivo.
- Carico vCPU sbilanciato che crea colli di bottiglia su alcuni worker outlier
Il job ha un numero sufficiente di vCPU worker, ma alcuni worker mostrano un utilizzo della vCPU molto elevato. Questo è spesso causato da una distribuzione del lavoro non uniforme. Le possibili cause includono partizioni di origine caricate in modo non uniforme o chiavi utilizzate di frequente.
Per risolvere il problema, prova quanto segue:
- Determina la causa del caricamento non uniforme e prova a correggerla. Ad esempio, assicurati che le partizioni di origine siano distribuite in modo uniforme.
- Se non è possibile correggere il carico non uniforme, valuta la possibilità di modificare la forma della VM worker per aumentare le vCPU per worker e ridurre l'utilizzo di picco. Per ulteriori informazioni sulla configurazione delle vCPU per worker, consulta Configurare le VM worker di Dataflow.
- Problema di comunicazione con i worker
Dataflow non riesce a comunicare con tutte le VM worker. Controlla lo stato delle VM worker del job. Tra le possibili cause rientrano:
- Si è verificato un problema durante il provisioning delle VM worker.
- Il pool di VM worker viene eliminato durante l'esecuzione del job.
- Problemi di Networking.
- L'origine Pub/Sub ha errori di pull.
Si sono verificati errori durante il pull dall'origine Pub/Sub. Verifica che esistano l'argomento e le sottoscrizioni richiesti e controlla la quota e la configurazione. Puoi anche controllare i log per verificare la presenza di errori.
- Origine Pub/Sub con parallelismo insufficiente
Il calcolo dell'origine Pub/Sub ha un numero insufficiente di chiavi Pub/Sub. Per aumentare il numero di chiavi, imposta l'opzione di servizio
num_pubsub_keys. Per ulteriori informazioni, consulta Parallelismo dell'origine Pub/Sub.- Origine Pub/Sub limitata per motivi sconosciuti
Il calcolo dell'origine Pub/Sub è limitato durante la lettura da Pub/Sub per un motivo sconosciuto. Questo problema potrebbe essere temporaneo. Verifica la presenza di problemi di configurazione di Pub/Sub, autorizzazioni IAM mancanti o limiti di quota. Tuttavia, se nessuna delle aree precedenti è la causa principale e il problema persiste, contatta l'assistenza.
- Pubblicazione del sink Pub/Sub lenta o bloccata
Il calcolo del sink Pub/Sub è lento o bloccato. Questo problema potrebbe essere causato da un problema di configurazione o da un limite di quota.
- Tempo di coda di lavoro elevato
L'età del lavoro idoneo più vecchia è elevata a causa di un numero elevato di chiavi e della velocità con cui vengono elaborate le chiavi. In questa situazione, ogni operazione potrebbe non essere eccessivamente lunga, ma il ritardo complessivo nella coda è elevato.
Dataflow utilizza un singolo thread di elaborazione per ogni chiave di sharding e il numero di thread di elaborazione è limitato. Il ritardo nella coda è approssimativamente uguale al rapporto tra chiavi e thread, moltiplicato per la latenza nel thread per ogni bundle di elaborazione per una chiave:
(key count / total harness threads) * latency per bundleProva le seguenti soluzioni:
- Aumenta il numero di worker. Consulta Scalabilità automatica di flusso.
- Aumenta il numero di thread dell'harness del worker. Imposta l'opzione della pipeline
numberOfWorkerHarnessThreads/number_of_worker_harness_threads. - Riduci il numero di chiavi.
- Riduci la latenza dell'operazione.
- Un problema temporaneo con il backend di Streaming Engine
Si è verificato un problema di configurazione o operativo con il backend di Streaming Engine. Questo problema potrebbe essere temporaneo. Se il problema persiste, contatta l'assistenza.
- Impossibile determinare la causa
Non è possibile determinare con certezza la causa del backlog. Questo problema potrebbe essere temporaneo. Se il problema persiste, contatta l'assistenza.
Metriche dei colli di bottiglia
Le seguenti metriche dei job forniscono informazioni sui colli di bottiglia:
dataflow.googleapis.com/job/is_bottleneck: un valore booleano che indica se la fase è un collo di bottiglia attivo, insieme alle etichette che specificano il tipo di collo di bottiglia e la causa probabile.dataflow.googleapis.com/job/backlogged_keys: il numero di chiavi di cui è stato eseguito il backup nella fase di collo di bottiglia.dataflow.googleapis.com/job/recommended_parallelism: il valore di parallelismo consigliato per alleviare il collo di bottiglia nella fase interessata.
Passaggi successivi
- Informazioni sul rilevatore di colli di bottiglia di Dataflow
- Rilevare e risolvere i colli di bottiglia della pipeline Dataflow
- Blog per il rilevatore di colli di bottiglia con scenari reali di job che non funzionano correttamente
- Risolvere i problemi relativi ai job lenti o bloccati
- Monitorare il rendimento della pipeline utilizzando Profiler