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 pode não enviar 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 runnable 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.

Saiba mais sobre esse problema:

  1. Se quiser mais informações sobre como e quando esse problema afeta os jobs, consulte Identificar e entender esse problema.
  2. Para saber como evitar ou resolver esse problema, consulte Resolver esse problema.

Identificar e entender esse 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 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 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.

Contornar esse problema

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.

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 tenha a versão mais recente do kernel. Esse problema também afeta imagens personalizadas baseadas em imagens de SO de VM do Compute Engine. 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. Embora esse problema possa ocorrer com qualquer imagem do Compute Engine (até mesmo a versão mais recente) a qualquer momento, observamos que ele é mais comum em imagens do Debian.

Saiba mais sobre esse problema:

  1. Se quiser mais informações sobre como e quando esse problema afeta os jobs, consulte Identificar e entender esse problema.
  2. Para saber como evitar ou resolver esse problema, consulte Resolver esse problema.

Identificar e entender esse problema

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.

Esse problema pode ocorrer a qualquer momento, mesmo que você use a versão mais recente de uma imagem do Compute Engine. Se um SO foi atualizado recentemente, especialmente para atualizações imprevisíveis, como hotfixes (atualizações urgentes para vulnerabilidades ou problemas críticos), as imagens do SO da VM do Compute Engine talvez não tenham conseguido reagir às mudanças ainda. Por exemplo, observamos que, no SO Debian, pacotes com prefixos linux-headers- podem ser removidos de forma imprevisível do kernel por hotfixes.

Para identificar esse problema, recomendamos que você veja os registros do job e verifique se há erros de instalação relacionados à imagem do SO da VM. Por exemplo, se o job usar uma imagem do Debian Compute Engine ou uma imagem personalizada semelhante, recomendamos que você verifique se há erros relacionados à instalação de pacotes linux-headers- especificando a seguinte consulta:

labels.job_uid="JOB_UID" AND severity="ERROR" AND textPayload:("failed" "apt" "install" "linux-headers-")

Substitua JOB_UID pelo ID exclusivo (UID) do job. Para receber o UID de um job, descreva o job. Se essa consulta retornar resultados, o problema pode estar afetando seu job.

Contornar esse problema

Para evitar ou resolver esse problema, recomendamos que você faça o seguinte:

  1. Sempre que possível, use imagens do Batch ou personalizadas com base em imagens do Batch, que não são afetadas por esse problema.

  2. Teste a versão mais recente da sua imagem preferida do Compute Engine. 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 versões anteriores.

  3. Escolha uma das seguintes opções:

    • Tente usar outro SO ou crie uma imagem personalizada. Por exemplo, se a versão mais recente do Debian 12 não funcionar, tente 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.

    • Se o job falhar devido a erros relacionados à instalação de pacotes linux-headers-, tente usar a imagem do SO da VM com pacotes linux-headers- desatualizados. Para permitir pacotes linux-headers- desatualizados, adicione um rótulo com o nome goog-batch-allow-insecure-linux-headers-installation e o valor true ao campo labels no nível do job.

      Por exemplo, para permitir pacotes linux-headers- desatualizados em um job de script básico que especifica uma imagem do SO da VM, 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": [
      {
        "policy": {
          "bootDisk": {
            "image": "VM_OS_IMAGE_URI"
          }
        }
      }
    ]
  },
  "labels": {
    "goog-batch-allow-insecure-linux-headers-installation": "true"
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

      Substitua VM_OS_IMAGE_URI pelo URI da imagem do SO da VM que você quer usar.

      Para mais instruções, consulte Definir rótulos personalizados para o job e Especificar a imagem do SO da VM para um 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 ao anterior, 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 esse problema e como resolvê-lo, consulte Os jobs podem falhar ao especificar imagens do SO de VM do Compute Engine (ou personalizadas) com kernels desatualizados. Para mais informações sobre GPUs, consulte Criar e executar um job que usa GPUs.