Um gargalo ocorre quando uma etapa, um estágio ou um worker atrasa o job geral. Gargalos podem levar a workers inativos e aumentar a latência.
Se o Dataflow detectar um gargalo, o gráfico de job vai mostrar um alerta, e o painel Informações da etapa vai listar o tipo de gargalo e a causa, se conhecida. O Dataflow também exporta informações de detecção de gargalos para uma métrica do Stackdriver, que apresenta os dados como uma série temporal. Assim, você pode ver gargalos ao longo do tempo ou no passado.
Entender gargalos
Quando o Dataflow executa um pipeline de streaming, o job consiste em uma série de componentes, como embaralhamentos de streaming, linhas de execução de processamento de função definida pelo usuário (DoFn
) e criação de pontos de verificação de estado persistente. Para facilitar o fluxo de dados, o Dataflow usa filas para conectar esses componentes. Os dados são enviados do upstream para o downstream.
Em muitos pipelines, a capacidade geral de transmissão é limitada por um único componente, criando um gargalo no pipeline. A taxa em que os dados podem passar por um gargalo limita a velocidade com que o pipeline pode aceitar e processar dados de entrada.
Por exemplo, considere um pipeline em que o processamento de DoFn
ocorre depois de uma
ordem aleatória de streaming. Uma fila entre eles armazena em buffer os dados embaralhados, mas não processados. Se o processamento de DoFn
não conseguir consumir dados tão rápido quanto a
permutação de streaming os produz, a fila vai aumentar. Um gargalo prolongado pode fazer com que a fila atinja a capacidade máxima. Nesse ponto, o embaralhamento é pausado, e o backlog é propagado para cima. As filas mais a montante também acumulam backlogs, causando uma lentidão que se estende à fonte de dados. Isso significa que todo o pipeline não consegue acompanhar a entrada.
Quando um gargalo acontece, uma parte substancial do pipeline pode parecer não íntegra, mesmo que um único ponto no pipeline esteja causando o acúmulo. Esse comportamento pode dificultar a depuração de gargalos. O objetivo da detecção de gargalos é identificar o local e a causa exatos, eliminando palpites, para que você possa corrigir a causa raiz.
O Dataflow detecta um gargalo quando um atraso excede o limite de cinco minutos. Se o atraso não ultrapassar esse limite, o Dataflow não vai detectar um gargalo.
A detecção de gargalos nem sempre exige que você tome medidas e depende do seu caso de uso. Um pipeline pode operar normalmente com atrasos temporários de mais de cinco minutos. Se isso for aceitável para seu caso de uso, talvez não seja necessário resolver os gargalos indicados.
Tipos de gargalo
Quando o Dataflow detecta um gargalo, a interface de monitoramento indica a gravidade do problema. Os gargalos se enquadram nas seguintes categorias:
- O processamento está travado.
- O progresso do pipeline é completamente interrompido nessa etapa.
- O processamento está progredindo, mas está atrasado.
- O pipeline não consegue processar os dados recebidos na mesma velocidade em que eles chegam. Como resultado, o backlog está crescendo.
- O processamento está progredindo, mas o backlog é estável
- O pipeline está progredindo, e a taxa de processamento é comparável à taxa de entrada. O processamento é rápido o suficiente para que o backlog não aumente, mas o backlog acumulado também não diminui significativamente.
- O processamento está progredindo e está se recuperando de um backlog
- O backlog está diminuindo, mas o gargalo atual impede que o pipeline recupere o atraso mais rápido. Se você iniciar um pipeline com um backlog, esse estado poderá ser normal e não exigir intervenção. Monitore o progresso para ver se o backlog continua diminuindo.
Causas de gargalos
A interface de monitoramento mostra a causa do gargalo, se conhecida. Use essas informações para resolver o problema.
- Operações com longo processamento
- Uma computação tem um longo tempo de processamento. Se o cálculo afetado estiver no código do usuário, procure maneiras de otimizar o código. Para ajudar na depuração, os registros do worker mostram rastreamentos de pilha de todas as operações que ficam travadas por mais de 5 minutos.
- Partições de origem do Apache Kafka insuficientes
O cálculo da origem do Apache Kafka tem partições insuficientes. Para resolver esse problema, tente o seguinte:
- Aumente o número de partições do Kafka.
- Use uma transformação
Redistribute
para redistribuir e paralelizar os dados de maneira mais eficiente.
Para mais informações, consulte Paralelismo na página Ler do Apache Kafka para o Dataflow.
- Paralelismo de origem insuficiente
Um cálculo de origem tem paralelismo insuficiente. Se possível, aumente a paralelização na origem. Se não for possível aumentar a paralelização e o job usar o modo pelo menos uma vez, tente adicionar uma transformação
Redistribute
ao pipeline.- Chaves com acesso frequente ou insuficiência de paralelismo entre as chaves
O job tem chaves com acesso frequente ou paralelismo insuficiente entre as chaves.
Para cada chave de fragmentação, o Dataflow processa as mensagens em série. Enquanto o Dataflow processa um lote de mensagens para uma determinada chave, outras mensagens recebidas para essa chave são enfileiradas até que o lote atual seja concluído.
Se o Dataflow não conseguir processar chaves distintas suficientes em paralelo, isso pode causar um gargalo. Por exemplo, os dados podem ter poucas chaves distintas ou algumas chaves podem estar super-representadas nos dados ("chaves ativas"). Para mais informações, consulte Resolver problemas de jobs lentos ou travados.
- vCPUs com provisionamento insuficiente
O job não tem vCPUs de worker suficientes. Essa situação ocorre quando o job já está escalonado ao máximo, a utilização da vCPU está alta e ainda há um backlog.
- Problema na comunicação com os workers
O Dataflow não consegue se comunicar com todas as VMs de worker. Verifique o status das VMs de trabalho do job. Estas são as possíveis causas:
- Ocorreu um problema ao provisionar as VMs de worker.
- O pool de VM de worker é excluído enquanto o job está em execução.
- Problemas de rede.
- A origem do Pub/Sub tem paralelismo insuficiente
O cálculo da origem do Pub/Sub tem um número insuficiente de chaves do Pub/Sub. Se você receber esse aviso, entre em contato com o suporte.
- A origem do Pub/Sub foi limitada por um motivo desconhecido
A computação de origem do Pub/Sub é limitada durante a leitura do Pub/Sub por um motivo desconhecido. Esse problema pode ser temporário. Verifique se há problemas de configuração do Pub/Sub, permissões do IAM ausentes ou limites de cota. No entanto, se nenhuma das áreas anteriores for a causa principal e o problema persistir, entre em contato com o suporte.
- A publicação do coletor do Pub/Sub está lenta ou travou
O cálculo do coletor do Pub/Sub está lento ou travou. Esse problema pode ser causado por um problema de configuração ou um limite de cota.
- Tempo alto na fila de trabalho
A idade de trabalho mais antiga qualificada é alta devido a um grande número de chaves e à taxa de processamento delas. Nessa situação, cada operação pode não ser anormalmente longa, mas o atraso geral na fila é alto.
O Dataflow usa uma única linha de execução de processamento por chave de fragmentação, e o número de linhas de execução de processamento é limitado. O atraso na fila é aproximadamente igual à proporção de chaves para linhas de execução, multiplicada pela latência na linha de execução de cada pacote de processamento para uma chave:
(key count / total harness threads) * latency per bundle
Tente as seguintes correções:
- Aumente o número de workers. Consulte Escalonamento automático de streaming.
- Aumente o número de linhas de execução de uso de worker. Defina a opção de pipeline
numberOfWorkerHarnessThreads
/number_of_worker_harness_threads
. - Diminua o número de chaves.
- Diminua a latência da operação.
- Um problema temporário com o back-end do Streaming Engine
Há um problema de configuração ou operacional com o back-end do Streaming Engine. Esse problema pode ser temporário. Se o problema persistir, entre em contato com o suporte.