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:

O pipeline não está lendo dados da origem. Por exemplo, o Pub/Sub tem um backlog crescente.
O pipeline não está gravando dados no coletor.
A métrica de atualização de dados está aumentando.
A métrica de latência do sistema está aumentando.

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

Investigar falhas repetidas

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:

Use as métricas de utilização da memória e procure erros de memória insuficiente nos registros do worker para verificar a pressão da memória. Para mais informações, consulte Resolver erros de memória insuficiente do Dataflow.
Se você estiver usando o Streaming Engine, utilize as métricas de persistência para identificar gargalos com as operações de entrada/saída (IOPS, na sigla em inglês) do disco.
Verifique se há outros erros nos registros do worker. Para mais informações, consulte Trabalhar com registros de pipeline e Resolver erros do Dataflow.

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 as partições do Pub/Sub.
A chave é explicitamente definida 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:

No console do Google Cloud, na página Informações do job, use a Guia de escalonamento automático para verificar se o job está com problemas para escalonar verticalmente. Se o problema for o escalonamento automático, consulte Resolver problemas de escalonamento automático do Dataflow.
Use o gráfico do job para verificar as etapas da fase. Se a fase estiver lendo de uma origem ou gravando em um coletor, revise a documentação do serviço da origem ou do coletor. Use a documentação para determinar se esse serviço está configurado para escalonabilidade suficiente.
- Para coletar mais informações, use as métricas de entrada e saída fornecidas pelo Dataflow.
- Se estiver usando o Kafka, verifique o número de partições dele. Para mais informações, consulte a documentação do Apache Kafka.
- Se você estiver usando um coletor do BigQuery, ative a fragmentação automática para melhorar o paralelismo. Para mais informações, consulte Aumento da capacidade de processamento do Dataflow em três vezes com fragmentação automática para o BigQuery.

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 conferir mais informações, consulte a classe Combine.PerKey no SDK do Java ou a operação with_hot_key_fanout (link em inglês) 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ê a entrada do Pub/Sub ou do BigQuery, é possível que o projeto do Google Cloud tenha 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 grande número de erros 429 (Rate Limit Exceeded), talvez ele tenha cota insuficiente. Para verificar se há erros, tente as seguintes etapas:

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

Use 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:

No Console do Google Cloud, selecione Monitoring:

Acessar Monitoring
No painel de navegação, selecione Metrics Explorer.
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 o worker com atraso nessa fase.
Se não houver workers com atraso, use o painel Informações da fase para identificar a etapa mais lenta. Use essas informações para identificar os candidatos à otimização do código do usuário.
Para encontrar gargalos de paralelismo, use as métricas de monitoramento do Dataflow.

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:

Conferir os arquivos de registros desse worker. Saiba mais em Monitorar e ver os registros do pipeline.
Veja as métricas de utilização da CPU e os detalhes do progresso do worker para workers em atraso. Se você perceber uma utilização excepcionalmente alta ou baixa da CPU, procure os seguintes problemas nos arquivos de registro desse worker:
- A hot key ... was detected
- Processing stuck ... Operation ongoing

Ferramentas para depuração

Quando o 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 o desempenho 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 fazer investigações 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 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.