Problemas conhecidos

Nesta página, descrevemos problemas conhecidos que você pode encontrar ao usar o Batch.

Se você precisar de mais ajuda para usar o Batch, consulte a documentação de Solução de problemas ou Receber suporte.

O Pub/Sub pode não enviar notificações para estados intermediários durante mudanças rápidas.

O Pub/Sub talvez não envie notificações para todos os estados intermediários quando um job ou uma tarefa muda muito rapidamente. Por exemplo, suponha que uma tarefa mude rapidamente de ASSIGNED para RUNNING e depois para FAILED. Nesse cenário, talvez você não receba uma notificação de que a tarefa atingiu o estado RUNNING.

Para evitar esse problema, recomendamos que, quando quiser conferir o histórico completo de estados de um job ou uma tarefa, veja os eventos de status em vez das notificações do Pub/Sub.

Para mais informações sobre notificações do Pub/Sub, consulte Monitorar o status do job usando notificações do Pub/Sub e o BigQuery.

Os registros de tempo limite não indicam se o tempo limite da tarefa ou do executável foi excedido

Quando um job falha por exceder um tempo limite, os registros associados a ele não indicam se a falha foi causada pelo tempo limite da tarefa relevante ou pelo tempo limite do executável relevante.

Para contornar esse problema, defina valores de tempo limite diferentes para tarefas e executáveis. Em seguida, é possível identificar se uma falha foi causada por exceder o tempo limite da tarefa ou do executável relevante usando o seguinte procedimento:

  1. Identifique a tarefa, o executável e o horário de uma falha de tempo limite excedido.

    1. Veja os registros do job.

    2. Encontre um registro que mencione o código de saída de tempo limite excedido, 50005. Esse registro tem um textPayload semelhante à seguinte mensagem:

      Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005

      Nesse registro, grave TASK_INDEX como a tarefa com falha, RUNNABLE_INDEX como o executável com falha e o valor timestamp do registro como o horário da falha de tempo limite excedido.

  2. Identifique o horário de início da tarefa com falha.

    1. Confira os eventos de status da tarefa com falha.

    2. Encontre o evento de status que menciona a seguinte mensagem:

      Task state is updated from ASSIGNED to RUNNING

      Nesse evento de status, registre o campo eventTime como o horário de início da tarefa com falha.

  3. Calcule o tempo total de execução da tarefa com falha, \({failedTaskRunTime}\), usando a seguinte fórmula:

    \[{failedTaskRunTime}={failureTime}-{failedTaskStartTime}\]

    Substitua os seguintes valores:

    • \({failureTime}\): o horário da falha de tempo limite excedido.
    • \({failedTaskStartTime}\): o horário de início da tarefa com falha.

  4. Identifique o tempo limite excedido:

    • Se \({failedTaskRunTime}\) corresponder ao tempo limite configurado para a tarefa com falha, isso significa que o tempo limite da tarefa foi excedido e causou a falha.

    • Caso contrário, o tempo limite configurado para o executável com falha foi excedido e causou a falha.

Os jobs que consomem reservas podem ser adiados ou impedidos

Ao tentar criar e executar um job que consome reservas do Compute Engine, o Batch pode atrasar ou impedir incorretamente a execução do job. Especificamente, o Batch exige que os projetos tenham cotas de recursos do Compute Engine suficientes, mesmo quando essas cotas são usadas por reservas não consumidas.

Solução alternativa

Para contornar esse problema em um job, adicione um rótulo com o nome goog-batch-skip-quota-check e o valor true ao campo labels no nível do job. Esse rótulo faz com que o Batch pule a verificação das cotas de recursos do projeto antes de tentar criar um job.

Por exemplo, para evitar ou resolver esse problema em um job de script básico que pode consumir reservas, crie e execute um job com a seguinte configuração JSON:

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ]
      },
      "taskCount": 3
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        VM_RESOURCES
      }
    ],
  },
  "labels": {
    "goog-batch-skip-quota-check": "true"
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

Substitua VM_RESOURCES pelos recursos de VM que correspondem à reserva que você quer que o job consuma.

Para mais instruções, consulte Criar e executar um job que pode consumir VMs reservadas e Definir rótulos personalizados para o job.

Identificar o problema

Esse problema não é indicado por nenhuma mensagem de erro específica. Em vez disso, esse problema pode acontecer nas seguintes circunstâncias:

  • Se o projeto reservar todos os recursos para os quais tem cota, esse problema impede qualquer job que especifique esses recursos.

    Por exemplo, suponha que seu projeto tenha o seguinte:

    • Uma cota máxima de 16 GPUs H100.
    • Uma reserva para um único projeto não consumida para duas VMs a3-highgpu-8g, que reserva 16 GPUs H100 no total.

    Nesse cenário, o problema impede que o projeto agende e execute qualquer job configurado corretamente para consumir qualquer uma das GPUs H100 reservadas.

  • Se o projeto reservar alguns dos recursos para os quais tem cota, esse problema poderá impedir ou atrasar jobs que especificam esses recursos.

    Por exemplo, suponha que seu projeto tenha o seguinte:

    • Uma cota máxima de 16 GPUs H100.
    • Uma reserva para um único projeto não consumida para uma VM a3-highgpu-8g, que reserva oito GPUs H100 no total.
    • Uma VM a3-highgpu-8g configurada para não consumir reservas e que é excluída e recriada ocasionalmente. Essa VM usa oito GPUs H100 não reservadas quando existe.

    Nesse cenário, o problema permite que seu projeto agende e comece a executar qualquer job configurado corretamente para consumir qualquer uma das GPUs H100 reservadas quando a VM a3-highgpu-8g não existe.

Os jobs podem falhar ao especificar imagens do SO de VMs do Compute Engine (ou personalizadas) com kernels desatualizados

Um job pode falhar se especificar uma imagem do SO de VM do Compute Engine que não tem a versão mais recente do kernel. Esse problema também afeta imagens personalizadas baseadas em imagens de SO de VM do Compute Engine. As imagens públicas do Compute Engine que causam esse problema não são facilmente identificadas e estão sujeitas a mudanças a qualquer momento.

Esse problema não é indicado por uma mensagem de erro específica. Em vez disso, considere este problema se você tiver um job que falhe inesperadamente e especifique uma imagem do SO da VM do Compute Engine ou uma imagem personalizada semelhante.

Para evitar ou resolver esse problema, faça o seguinte:

  1. Sempre que possível, use imagens em lote ou personalizadas com base em imagens em lote, que não são afetadas por esse problema.
  2. Se não for possível usar uma imagem do Batch, tente a versão mais recente da imagem do Compute Engine de sua preferência. Em geral, as versões mais recentes das imagens do Compute Engine têm mais chances de ter a versão mais recente do kernel do que as mais antigas.
  3. Se a versão mais recente de uma imagem específica não funcionar, talvez seja necessário testar outro SO ou criar uma imagem personalizada. Por exemplo, se a versão mais recente do Debian 11 não funcionar, você poderá tentar criar uma imagem personalizada de uma VM do Compute Engine que execute o Debian 11 e que você tenha atualizado para usar a versão mais recente do kernel.

Esse problema é causado por uma versão desatualizada do kernel na imagem do SO da VM, o que faz com que ela seja reinicializada. Quando um job especifica uma imagem do SO da VM que não é do Batch ou baseada em uma imagem do Batch, o Batch instala os pacotes necessários nas VMs do job depois que elas são iniciadas. Os pacotes necessários podem variar para diferentes jobs e mudar com o tempo, e podem exigir que a imagem do SO da VM tenha a versão mais recente do kernel. Esse problema aparece quando a atualização da versão do kernel exige a reinicialização da VM, o que causa a falha na instalação do pacote e no job.

Para mais informações sobre imagens de SO de VM, consulte Visão geral do ambiente de SO para VMs de um job.

Os jobs que usam GPUs e imagens de SO de VM com kernels desatualizados podem falhar apenas ao instalar drivers automaticamente.

Esse problema está intimamente relacionado a Os jobs podem falhar ao especificar imagens do SO de VMs do Compute Engine (ou personalizadas) com kernels desatualizados. Especificamente, os jobs que especificam uma imagem do SO da VM do Compute Engine (ou personalizada) sem o kernel mais recente e usam GPUs podem falhar somente se você tentar instalar drivers de GPU automaticamente. Para esses jobs, também é possível resolver as falhas apenas instalando drivers de GPU manualmente.

Para mais informações sobre GPUs, consulte Criar e executar um job que usa GPUs.