Problemas conhecidos

Esta página descreve 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 entre em contato com o suporte.

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

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

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

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

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

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

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

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

    1. Consulte 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. Consulte 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, grave 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}\) for igual ao tempo limite configurado para a tarefa com falha, o tempo limite dessa 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 atrasados ou impedidos

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

Solução alternativa para o problema

Para solucionar 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, ele pode acontecer nas seguintes circunstâncias:

  • Se o projeto reservar todos os recursos para os quais tem cota, esse problema impedirá 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 de projeto único não consumida para duas VMs a3-highgpu-8g, que reserva 16 GPUs H100 no total.

    Nesse cenário, esse problema impede que o projeto programe 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 especifiquem esses recursos.

    Por exemplo, suponha que seu projeto tenha o seguinte:

    • Uma cota máxima de 16 GPUs H100.
    • Uma reserva de projeto único não consumida para uma VM a3-highgpu-8g, que reserva 8 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 8 GPUs H100 não reservadas quando existe.)

    Nesse cenário, esse problema só permite que o projeto programe 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 VM do Compute Engine (ou personalizadas) com kernels desatualizados

Um job poderá falhar se especificar uma imagem do SO de VM do Compute Engine que não tenha a versão mais recente do kernel. Esse problema também afeta imagens personalizadas com base em imagens do 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 esse problema se você tiver um job que falha inesperadamente e especifica uma imagem do SO de 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 do Batch ou imagens personalizadas com base em imagens do Batch, 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 preferida. Geralmente, as versões mais recentes das imagens do Compute Engine têm maior probabilidade de ter a versão mais recente do kernel do que as versões mais antigas.
  3. Se a versão mais recente de uma imagem específica não funcionar, talvez seja necessário tentar um SO diferente ou criar uma imagem personalizada. Por exemplo, se a versão mais recente do Debian 12 não funcionar, você pode tentar criar uma imagem personalizada de uma VM do Compute Engine que execute o Debian 12 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 que faz com que a VM seja reinicializada. Quando um job especifica qualquer imagem do SO de VM que não seja do Batch ou com base 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 ao longo do tempo, e eles 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 que a VM seja reinicializada, o que faz com que a instalação do pacote e o job falhem.

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

Os jobs que usam GPUs e imagens do 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 VM do Compute Engine (ou personalizadas) com kernels desatualizados. Especificamente, os jobs que especificam uma imagem do SO de VM do Compute Engine (ou personalizada) sem o kernel mais recente e usam GPUs podem falhar apenas 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.