Resolver problemas de jobs lentos ou travados

Nesta página, explicamos como resolver problemas comuns de streaming e jobs em lote lentos ou travados do Dataflow.

Streaming

Se você notar os seguintes sintomas, talvez o job de streaming do Dataflow esteja sendo executado lentamente ou esteja travado:

Use as informações das seções a seguir para identificar e diagnosticar o problema.

Identificar a causa raiz

  1. Verifique as métricas de atualização de dados e bytes de pendência.

    • Se as duas métricas estiverem aumentando monotonicamente, isso significa que o pipeline está parado e não progredindo.
    • Se a atualização de dados estiver aumentando, mas os bytes de backlog permanecerem normais, isso significa que um ou mais itens de trabalho estão presos no pipeline.

    Procure as etapas em que essas métricas estão aumentando para identificar qualquer etapa com problemas e as operações realizadas nela.

  2. Verifique o gráfico de processamento paralelo para saber se alguma etapa está travada devido a paralelismo excessivo ou insuficiente. Consulte Resolver problemas de paralelismo.

  3. Verifique os registros de jobs para problemas como limites de cota, falta de estoque ou esgotamento de endereços IP.

  4. Verifique os registros do worker em busca de avisos e erros.

    • Se os registros do worker contiverem erros, consulte o stack trace. Investigue se o erro é causado por um bug no seu código.
    • Procure erros do Dataflow. Confira Resolver erros do Dataflow.
    • Procure erros que mostrem que o job excedeu um limite, como o tamanho máximo da mensagem do Pub/Sub.
    • Procure erros de falta de memória, que podem causar um pipeline travado. Se você encontrar erros de falta de memória, siga as etapas em Resolver erros de falta de memória do Dataflow.
    • Para identificar uma etapa lenta ou travada, verifique as mensagens Operation ongoing nos registros do worker. Confira o stack trace para saber onde a etapa está gastando tempo. Para mais informações, consulte Processamento travado ou operação em andamento.

  5. Se um item de trabalho estiver preso em um worker específico, reinicie a VM de worker.

  6. Se você não estiver usando o Streaming Engine, verifique os registros do shuffler para avisos e erros. Se você encontrar um erro de tempo limite de RPC na porta 12345 ou 12346, talvez o job esteja sem uma regra de firewall. Consulte Regras de firewall para o Dataflow.

  7. Verificar se há chaves de uso intenso.

  8. Se o Runner v2 estiver ativado, verifique os registros do harness para encontrar erros. Para mais informações, consulte Resolver problemas do Runner v2.

Investigar falhas recorrentes

Em um job de streaming, algumas falhas são repetidas indefinidamente. Essas novas tentativas impedem o progresso do pipeline. Para identificar falhas repetidas, verifique se há exceções nos registros do worker.

  • Se a exceção for o código do usuário, depure e corrija o problema do código ou dos dados.
  • Para evitar que falhas inesperadas paralisem o pipeline, implemente uma fila de mensagens inativas. Para conferir um exemplo de implementação, consulte Padrões do BigQuery na documentação do Apache Beam.
  • Se a exceção for um erro de memória insuficiente (OOM, na sigla em inglês), consulte Como resolver erros de memória insuficiente do Dataflow.
  • Para outras exceções, consulte Resolver erros do Dataflow.

Identificar workers não íntegros

Se os workers que processam o job de streaming não estiverem íntegros, o job pode ficar lento ou parecer travado. Para identificar workers não íntegros:

Identificar stragglers

Um straggler é um item de trabalho lento em relação a outros itens de trabalho da fase. Para informações sobre como identificar e corrigir stragglers, consulte Resolver problemas de stragglers em jobs de streaming.

Resolver problemas de paralelismo

Para escalonabilidade e eficiência, o Dataflow executa as fases do pipeline em paralelo em vários workers. A menor unidade de processamento paralelo do Dataflow é uma chave. As mensagens recebidas para cada fase combinada são associadas a uma chave. A chave é definida de uma das seguintes maneiras:

  • A chave é definida implicitamente pelas propriedades da origem, como partições do Kafka.
  • A chave é definida explicitamente pela lógica de agregação no pipeline, como GroupByKey.

No Dataflow, as linhas de execução do worker são responsáveis por processar pacotes de trabalho (mensagens) para uma chave. O número de linhas de execução disponíveis para processar as chaves do job é igual a num_of_workers * threads_per_worker. A contagem de linhas de execução por worker é determinada com base no SDK (Java, Python ou Go) e no tipo de job (lote ou streaming).

Se o pipeline não tiver chaves suficientes para uma determinada fase, ele vai limitar o processamento paralelo. Essa fase pode se tornar um gargalo.

Se o pipeline usar um número muito grande de chaves em um determinado estágio, isso poderá limitar a capacidade de processamento do estágio e acumular backlog nos estágios upstream, porque há alguma sobrecarga por chave. O excesso pode incluir a comunicação do back-end com os workers, RPCs externos para um destino, como o BigQuery, e outros processamentos. Por exemplo, se o processamento de uma chave com uma mensagem levar 100 ms, também poderá levar cerca de 100 ms para processar 1.000 mensagens nesse pacote de chaves.

Identificar fases com baixo paralelismo

Para identificar se a lentidão do pipeline é causada por baixo paralelismo, consulte as métricas de utilização da CPU. Se a CPU estiver baixa, mas distribuída de maneira uniforme entre os workers, o job pode ter paralelismo insuficiente. Se o job estiver usando o Streaming Engine, consulte as métricas de paralelismo na guia Métricas do job para verificar se uma fase tem baixo paralelismo. Para minimizar esse problema:

Identificar fases com alto paralelismo

Uma combinação de baixa latência do sistema, atualização crescente de dados e aumento do backlog e das CPUs do worker subutilizadas sugere que o pipeline está sendo limitado devido a um grande número de chaves. Confira o gráfico de processamento paralelo para identificar estágios com um grande número de chaves.

Transformações como Reshuffle podem gerar milhões de chaves se você não especificar explicitamente withNumBuckets. Um grande número de chaves pode levar à criação de vários pacotes de trabalho menores, cada um exigindo uma linha de execução de worker dedicada para processamento. Como as linhas de execução de workers disponíveis são limitadas, isso pode levar a um backlog significativo de chaves de processamento, causando atrasos enquanto elas aguardam recursos. Como resultado, as linhas de execução de trabalho não são usadas de maneira eficiente.

Recomendamos limitar o número de chaves definindo a opção withNumBuckets na transformação Reshuffle. O valor não pode exceder o número total de threads em todos os workers. As chaves de segmentação (threads_per_worker * max_workers) no pipeline podem não ser ideais. Às vezes, é possível usar menos chaves e pacotes maiores, que são processados com mais eficiência pelo Dataflow devido ao uso de menos workers. Um número menor de chaves cria pacotes de trabalho maiores, que usam com eficiência as linhas de execução do worker e aumentam a capacidade da etapa.

Se houver várias etapas Reshuffle no pipeline, divida o número total de linhas de execução pela contagem de etapas Reshuffle para calcular withNumBuckets.

Verificar se há chaves de uso intenso

Se as tarefas forem distribuídas de maneira desigual entre os workers e a utilização deles for muito desigual, talvez o pipeline tenha uma chave de uso intenso. Uma chave de uso intenso tem muito mais elementos para processar em comparação com outras chaves.

Verifique se há chaves de uso intenso usando o seguinte filtro de registro:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.line:"hot_key_logger"

Substitua JOB_ID pelo ID do job.

Para resolver esse problema, siga uma ou mais destas etapas:

  • Faça o rechaveamento dos dados. Para gerar novos pares de chave-valor, aplique uma transformação ParDo. Para mais informações, consulte a página de transformação ParDo do Java ou a página de transformação ParDo do Python na documentação do Apache Beam.
  • Use .withFanout nas transformações de combinação. Para mais informações, consulte a classe Combine.PerKey no SDK do Java ou a operação with_hot_key_fanout no SDK do Python.
  • Se você tiver um pipeline Java que processa PCollections ilimitados de alto volume, recomendamos fazer o seguinte:
    • Use Combine.Globally.withFanout, em vez de Combine.Globally.
    • Use Combine.PerKey.withHotKeyFanout, em vez de Count.PerKey.

Verificar se há cota insuficiente

Verifique se há cota suficiente para a origem e o coletor. Por exemplo, se o pipeline lê entradas do Pub/Sub ou do BigQuery, o projeto Google Cloud pode ter uma cota insuficiente. Para mais informações sobre limites de cota para esses serviços, consulte Cota do Pub/Sub ou Cota do BigQuery.

Se o job estiver gerando um alto número de erros 429 (Rate Limit Exceeded), talvez a cota seja insuficiente. Para verificar se há erros, tente as seguintes etapas:

  1. Acesse o console doGoogle Cloud .
  2. No painel de navegação, clique em APIs e serviços.
  3. No menu, clique em Biblioteca.
  4. Use a caixa de pesquisa para procurar Pub/Sub.
  5. Clique em API Cloud Pub/Sub.
  6. Selecione Gerenciar.
  7. No gráfico Tráfego por código de resposta, procure códigos de erro de cliente (4xx).

Você também pode usar o Metrics Explorer para verificar o uso da cota. Se o pipeline usar uma origem ou um coletor do BigQuery, use as métricas da API BigQuery Storage para resolver problemas de cota. Por exemplo, para criar um gráfico que mostre a contagem de conexões simultâneas do BigQuery, siga estas etapas:

  1. No console Google Cloud , selecione Monitoring:

    Acessar Monitoring

  2. No painel de navegação, selecione Metrics Explorer.

  3. No painel Selecionar uma métrica, em Métrica, filtre Projeto do BigQuery > Gravar > Contagem de conexões simultâneas.

Para instruções sobre como visualizar métricas do Pub/Sub, consulte Monitorar o uso da cota em "Monitorar o Pub/Sub no Cloud Monitoring". Para instruções sobre como conferir métricas do BigQuery, consulte Visualizar o uso e os limites de cota em "Criar painéis, gráficos e alertas".

Lote

Se o job em lote estiver lento ou travado, use a guia Detalhes da execução para encontrar mais informações sobre o job e identificar a fase ou worker que está causando um gargalo.

Identificar a causa raiz

  1. Verifique se o job está enfrentando problemas durante a inicialização do worker. Para mais informações, consulte Erro ao sincronizar o pod.

    Para verificar se o job começou a processar dados, procure no registro job-message a seguinte entrada de registro:

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

  2. Para comparar o desempenho de diferentes jobs, verifique se o volume de dados de entrada, a configuração do worker, o comportamento de escalonamento automático e as configurações do Dataflow Shuffle são os mesmos.

  3. Verifique os registros de job-message para problemas como limites de cota, falta de estoque ou esgotamento de endereços IP.

  4. Na guia Detalhes da execução, compare o progresso da etapa para identificar as que levaram mais tempo.

  5. Procure por fios restantes no job. Para mais informações, consulte Resolver problemas de stragglers em jobs em lote.

  6. Verifique as métricas de capacidade, CPU e utilização da memória.

  7. Verifique os registros do worker em busca de avisos e erros.

  8. Verificar se há chaves de uso intenso.

  9. Se você não estiver usando o Dataflow Shuffle, verifique os registros do shuffler para avisos e erros durante a operação de embaralhamento. Se você encontrar um erro de tempo limite de RPC na porta 12345 ou 12346, talvez o job esteja sem uma regra de firewall. Consulte Regras de firewall para o Dataflow.

  10. Se o Runner v2 estiver ativado, verifique os registros de harness para encontrar erros. Para mais informações, consulte Resolver problemas do Runner v2.

Identificar stragglers

Um straggler é um item de trabalho lento em relação a outros itens de trabalho da fase. Para saber mais sobre como identificar e corrigir stragglers, consulte Resolver problemas de stragglers em jobs em lote.

Identificar fases lentas ou travadas

Para identificar fases lentas ou travadas, use a visualização Progresso da fase. As barras mais longas indicam que o estágio leva mais tempo. Use essa visualização para identificar as fases mais lentas do pipeline.

Depois de encontrar a fase de gargalo, siga estas etapas:

Identifique um worker com atraso

Para identificar um worker com atraso de uma fase específica, use a visualização Progresso do worker. Essa visualização mostra se todos os workers estão processando o trabalho até o final da fase ou se um único worker está parado em uma tarefa atrasada. Se você encontrar um worker com atraso, siga as etapas a seguir:

Ferramentas para depuração

Quando um pipeline está lento ou travado, as ferramentas a seguir podem ajudar a diagnosticar o problema.

  • Para correlacionar incidentes e identificar gargalos, use o Cloud Monitoring para Dataflow.
  • Para monitorar a performance do pipeline, use o Cloud Profiler.
  • Algumas transformações são mais adequadas para pipelines de alto volume do que outras. As mensagens de registro podem identificar uma transformação de usuário travada em pipelines em lote ou de streaming.
  • Para saber mais sobre um job travado, use as métricas de job do Dataflow. A lista a seguir tem métricas úteis:
    • A métrica Bytes de backlog (backlog_bytes) mede a quantidade de entrada não processada em bytes por fase. Use essa métrica para encontrar uma etapa combinada que não tenha capacidade de processamento. Da mesma forma, a métrica de elementos do backlog (backlog_elements) mede o número de elementos de entrada não processados de uma fase.
    • A métrica Chaves de paralelismo de processamento (processing_parallelism_keys) mede o número de chaves de processamento paralelo para uma fase específica do pipeline nos últimos cinco minutos. Use essa métrica para investigar das seguintes maneiras:
      • Restrinja o problema a fases específicos e confirme os avisos de teclas de atalho, como A hot key ... was detected.
      • Encontre gargalos de capacidade de processamento causados por paralelismo insuficiente. Esses gargalos podem resultar em pipelines lentos ou travados.
    • A métrica de atraso do sistema (system_lag) e a métrica de atraso do sistema por fase (per_stage_system_lag) medem o tempo máximo que um item de dados ficou em processamento ou aguardando processamento. Use essas métricas para identificar fases e gargalos ineficientes das fontes de dados.

Para conferir outras métricas não incluídas na interface da Web de monitoramento do Dataflow, consulte a lista completa de métricas do Dataflow em métricas doGoogle Cloud .