Problemas conhecidos

Esta página descreve problemas conhecidos que você pode encontrar ao usar em lote.

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

Os logs de tempo limite não indicam se o tempo limite da tarefa ou da execução foi excedido.

Quando um job falha por exceder um tempo limite, os registros associados ao job não indicam se a falha foi causado pelo tempo limite da tarefa relevante ou do 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 excesso de tempo limite da tarefa ou da execução relevante usando o seguinte procedimento:

  1. Identificar a tarefa, a execução e o tempo de tempo limite excedido falha.

    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 a esta 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 tempo 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 de execução total da tarefa com falha, \({failedTaskRunTime}\), usando a seguinte fórmula:

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

    Substitua os seguintes valores:

    • \({failureTime}\): o tempo 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}\) corresponder ao tempo limite configurado para a tarefa com falha, o tempo limite dessa tarefa foi excedido e causado a falha.

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

Os jobs que consomem reservas podem atrasar ou ser impedidos

Quando você tenta criar e executar um job que consome reservas do Compute Engine, o lote pode atrasar ou impedir incorretamente a execução do job. Especificamente, o Batch exige que os projetos têm informações suficientes Cotas de recursos do Compute Engine mesmo quando essas cotas estão sendo usadas por reservas não consumidas.

Solução alternativa para o problema

Para contornar esse problema de um job, adicione um rótulo com o nome goog-batch-skip-quota-check e valor true para o campo labels no nível da vaga. Esse rótulo faz com que o lote pule a verificação das cotas de recursos do seu 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, problema pode acontecer nas seguintes circunstâncias:

  • Se o projeto reservar todos os recursos para os quais tem cota, esse problema vai impedir que os jobs que especificam esses recursos sejam executados.

    Por exemplo, suponha que seu projeto tenha o seguinte:

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

    Neste cenário, esse problema impede que seu projeto programar e executar qualquer job configurado corretamente para consumir qualquer uma das GPUs H100 reservadas.

  • Se o seu projeto reservar alguns dos recursos para os quais tem cota, pode impedir ou atrasar jobs que especificam esses recursos.

    Por exemplo, suponha que seu projeto tenha o seguinte:

    • Uma cota máxima de 16 para GPUs H100.
    • Uma reserva de projeto único e 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 nenhuma reserva e que é excluída e recriada ocasionalmente. Essa VM usa oito GPUs H100 não reservadas quando existe.

    Nesse cenário, esse problema só permite que seu projeto programe e inicie a execução de qualquer job que esteja 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

Uma atividade 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 todas as imagens personalizadas baseadas em imagens do SO da VM do Compute Engine. As imagens públicas do Compute Engine que causam esse problema não são facilmente identificados e estão sujeitos a alterações 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 falha 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 do lote ou personalizadas com base nas imagens do lote, que não são afetadas por esse problema.
  2. Se não for possível usar uma imagem do lote, tente a versão mais recente da sua 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 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 11 não funcionar, tente criar uma imagem personalizada em 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 no 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 é do Batch ou baseada em uma imagem do Batch, o Batch instala os pacotes necessários nas VMs do job após a inicialização. Os pacotes necessários podem variar para diferentes trabalhos e mudar com o tempo, e podem exigir imagem do SO da VM para ter a versão mais recente do kernel. Este problema aparece ao atualizar a versão do kernel exige que a VM seja reinicializada, o que faz com que na instalação do pacote e o job falhar.

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

Jobs que usam GPUs e imagens do SO da VM com kernels desatualizados podem falhar apenas na instalação automática de drivers

Esse problema está intimamente relacionado a Jobs might fail when specifying Compute Engine (or custom) VM OS images with outdated kernels. 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 da GPU automaticamente. Para esses jobs, também é possível resolver as falhas apenas instalar drivers de GPU manualmente.

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