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.

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 íntegras

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 íntegras:

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 insuficiente

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 Pub/Sub.
  • A chave é definida explicitamente pela lógica de agregação no pipeline, como GroupByKey.

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.

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, confira essas informações:

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. Para resolver esse problema, siga uma ou mais das seguintes 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 ler a entrada do Pub/Sub ou do BigQuery, é possível que seu projeto do Google Cloud tenha 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), a cota pode ser insuficiente. Para verificar se há erros, tente as seguintes etapas:

  1. Acesse o Console do Google 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 o 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 do 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 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. Barras mais longas indicam que a fase 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 você tem um pipeline 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 do 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 da seguinte maneira:
      • 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 conferiur 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 do Google Cloud.