Problemas conhecidos

Esta página descreve problemas conhecidos que podem ser encontrados ao usar o Batch.

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

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 do executável relevante.

Para solucionar esse problema, defina diferentes valores de tempo limite para tarefas e executáveis. Assim, é possível identificar se uma falha foi causada ao exceder o tempo limite da tarefa relevante ou se ela pode ser executada usando o seguinte procedimento:

  1. Identifique a tarefa, a 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, registre 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. Conferir 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

      A partir desse 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}={failedTime}-{failedTaskStartTime}\]

    Substitua os seguintes valores:

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

  4. Identifique o tempo limite excedido:

    • Se \({failedTaskRunTime}\) corresponde ao tempo limite configurado para a tarefa com falha, isso significa que o tempo limite da tarefa com falha 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 evitados

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 está exigindo 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 do 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 ignore a verificação das cotas de recursos do seu projeto antes de tentar criar um job.

Por exemplo, para evitar ou resolver esse problema de 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 correspondentes à reserva que você quer que o job consuma.

Para mais instruções, consulte Criar e executar um job que possa 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 ele tem cota, esse problema vai impedir os jobs que especificarem 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 um total de 16 GPUs H100.

    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 ele 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 de projeto único não consumida para uma VM a3-highgpu-8g, que reserva um total de 8 GPUs H100.
    • Uma VM a3-highgpu-8g configurada para não consumir reservas e, ocasionalmente, ser excluída e recriada. Esta 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 existir.

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

Um job poderá falhar se especificar uma imagem do SO da VM do Compute Engine que não tenha a versão mais recente do kernel. Esse problema também afeta todas as imagens personalizadas com base nas imagens do SO da 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 alterações 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 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 em lote, tente a versão mais recente da imagem preferida do Compute Engine. Geralmente, as versões mais recentes das imagens do Compute Engine têm mais chances de ter a versão do kernel mais recente 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 testar um SO diferente ou criar uma imagem personalizada. Por exemplo, se a versão mais recente do Debian 11 não funcionar, tente criar uma imagem personalizada em uma VM do Compute Engine que executa o Debian 11 e que você atualizou 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 da VM que não seja do Batch ou baseada em uma imagem em lote, o Batch instala os pacotes necessários nas VMs do job depois que eles são iniciados. Os pacotes necessários podem variar para diferentes jobs e mudar ao longo do tempo, além de exigir que a imagem do SO da VM tenha a versão mais recente do kernel. Esse problema aparece ao atualizar a versão do kernel exige que a VM seja reiniciada, o que faz com que a instalação do pacote e o job falhem.

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

Os jobs que usam GPUs e imagens de SO da VM com kernels desatualizados podem falhar apenas com a instalação automática de drivers

Esse problema está intimamente relacionado a Os jobs podem falhar ao especificar imagens do SO da VM 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 apenas se você tentar instalar os drivers de GPU automaticamente. Para esses jobs, também é possível resolver as falhas instalando drivers de GPU manualmente.

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