Problemas conhecidos

Esta página descreve problemas conhecidos que pode encontrar ao usar o Batch.

Se precisar de mais ajuda para usar o processamento em lote, consulte a documentação de Resolução de problemas ou receba apoio técnico.

O Pub/Sub pode não enviar notificações para estados intermédios durante alterações rápidas

O Pub/Sub pode não enviar notificações para todos os estados intermédios quando uma tarefa ou um trabalho muda muito rapidamente. Por exemplo, suponha que uma tarefa muda rapidamente de estados de ASSIGNED para RUNNING e, em seguida, para FAILED. Nesse cenário, pode não receber uma notificação a indicar que a tarefa atingiu o estado RUNNING.

Para mitigar este problema, recomendamos que, quando quiser ver o histórico de estados completo de um trabalho ou uma tarefa, veja os eventos de estado em vez das notificações do Pub/Sub.

Para mais informações sobre as notificações do Pub/Sub, consulte o artigo Monitorize o estado das tarefas através das notificações do Pub/Sub e do BigQuery.

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

Quando uma tarefa falha devido ao excesso de um limite de tempo, os registos associados à tarefa não indicam se a falha foi causada pelo limite de tempo da tarefa relevante ou pelo limite de tempo do executável relevante.

Para contornar este problema, defina valores de tempo limite diferentes para tarefas e runnables. Em seguida, pode identificar se uma falha foi causada por exceder o limite de tempo da tarefa ou do executável relevante através do seguinte procedimento:

1. Identificar a tarefa, o executável e a hora de uma falha de tempo limite excedido.

   1. Veja os registos da tarefa.

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

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

      A partir desse registo, registe TASK_INDEX como a tarefa com falha, RUNNABLE_INDEX como o executável com falha e o valor timestamp do registo como a hora da falha de tempo limite excedido.

2. Identifique a hora de início da tarefa com falha.

   1. Veja os eventos de estado da tarefa com falha.

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

      Task state is updated from ASSIGNED to RUNNING
      

      A partir desse evento de estado, registe o campo eventTime como a hora de início da tarefa com falha.

3. Calcule o tempo de execução total da tarefa com falhas, \({failedTaskRunTime}\), através da seguinte fórmula:

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

   Substitua os seguintes valores:

   • \({failureTime}\): a hora da falha de tempo limite excedido.
   • \({failedTaskStartTime}\): a hora de início da tarefa com falha.

4. Identifique o limite de tempo excedido:

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

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

As tarefas que consomem reservas podem sofrer atrasos ou ser impedidas

Quando tenta criar e executar uma tarefa que consuma reservas do Compute Engine, o Batch pode atrasar ou impedir incorretamente a execução da tarefa. Especificamente, o Batch requer que os projetos tenham quotas de recursos do Compute Engine suficientes, mesmo quando essas quotas de recursos estão a ser usadas por reservas não consumidas.

Contorne o problema

Para contornar este problema para uma tarefa, adicione uma etiqueta com o nome goog-batch-skip-quota-check e o valor true ao campo labels ao nível da tarefa. Esta etiqueta faz com que o Batch ignore a validação das quotas de recursos do seu projeto antes de tentar criar uma tarefa.

Importante: não é recomendável ativar a etiqueta goog-batch-skip-quota-check para tarefas que não podem consumir reservas no seu projeto. Por exemplo, evite esta solução alternativa quando o seu projeto não tiver reservas do Compute Engine ou quando um trabalho exigir VMs que não sejam compatíveis com essas reservas. Caso contrário, se os trabalhos ignorarem desnecessariamente as verificações de quota, pode ver falhas de quota insuficiente desnecessárias.

Por exemplo, para evitar ou resolver este problema para uma tarefa de script básica que possa consumir reservas, crie e execute uma tarefa 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 quer que a tarefa consuma.

Para mais instruções, consulte os artigos Crie e execute uma tarefa que possa consumir VMs reservadas e Defina etiquetas personalizadas para a tarefa.

Identifique o problema

Este problema não é indicado por nenhuma mensagem de erro específica. Em alternativa, este problema pode ocorrer nas seguintes circunstâncias:

• Se o seu projeto reservar todos os recursos para os quais tem quota, este problema impede todas as tarefas que especificam esses recursos.

  Por exemplo, suponha que o seu projeto tem o seguinte:

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

  Neste cenário, este problema impede que o seu projeto agende e execute qualquer tarefa que esteja corretamente configurada para consumir qualquer uma das GPUs H100 reservadas.

• Se o seu projeto reservar alguns dos recursos para os quais tem quota, este problema pode impedir ou atrasar as tarefas que especificam esses recursos.

  Por exemplo, suponha que o seu projeto tem o seguinte:

  • Uma quota máxima de 16 GPUs H100.
  • Uma reserva de projeto único não consumida para 1 VM, que reserva um total de 8 GPUs H100.a3-highgpu-8g
  • Uma VM configurada para não consumir reservas e que é ocasionalmente eliminada e, em seguida, recriada.a3-highgpu-8g (Esta VM usa 8 GPUs H100 não reservadas quando existe.)

  Neste cenário, este problema só permite que o seu projeto agende e comece a executar qualquer tarefa que esteja corretamente configurada para consumir qualquer uma das GPUs H100 reservadas quando a VM a3-highgpu-8g não existe.

As tarefas podem falhar quando especifica imagens de SO de VMs do Compute Engine (ou personalizadas) com kernels desatualizados

Uma tarefa pode falhar se especificar uma imagem do SO de VM do Compute Engine que não tenha a versão mais recente do kernel. Este problema também afeta quaisquer imagens personalizadas baseadas em imagens do SO da VM do Compute Engine. As imagens públicas do Compute Engine que causam este problema não são facilmente identificadas e estão sujeitas a alterações em qualquer altura.

Este problema não é indicado por uma mensagem de erro específica. Em alternativa, considere este problema se tiver uma tarefa que falha inesperadamente e especifica uma imagem do SO de VM do Compute Engine ou uma imagem personalizada semelhante.

Para evitar ou resolver este problema, pode fazer o seguinte:

Nota: se a sua tarefa usar GPUs, consulte também o artigo As tarefas que usam GPUs e imagens de SO de VMs com kernels desatualizados falham apenas quando os controladores são instalados automaticamente.

1. Sempre que possível, use imagens em lote ou imagens personalizadas baseadas em imagens em lote, que não são afetadas por este problema.
2. Se não conseguir usar uma imagem do Batch, experimente a versão mais recente da sua 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, pode ter de experimentar um SO diferente ou criar uma imagem personalizada. Por exemplo, se a versão mais recente do Debian 11 não funcionar, pode tentar criar uma imagem personalizada a partir de uma VM do Compute Engine que execute o Debian 11 e que tenha atualizado para usar a versão mais recente do kernel.

Este problema é causado por uma versão desatualizada do kernel na imagem do SO da VM, o que faz com que a VM seja reiniciada. Quando uma tarefa especifica uma imagem do SO de VM que não é do Batch nem se baseia numa imagem do Batch, o Batch instala os pacotes necessários nas VMs da tarefa depois de estas serem iniciadas. Os pacotes necessários podem variar para diferentes trabalhos e mudar ao longo do tempo, e podem exigir que a imagem do SO da VM tenha a versão mais recente do kernel. Este problema ocorre quando a atualização da versão do kernel requer o reinício da MV, o que faz com que a instalação do pacote e a tarefa falhem.

Para mais informações sobre imagens do SO de VMs, consulte o artigo Vista geral do ambiente do SO para as VMs de uma tarefa.

Os trabalhos que usam GPUs e imagens do SO de VMs com kernels desatualizados podem falhar apenas quando os controladores são instalados automaticamente

Este problema está estreitamente relacionado com o seguinte: Os trabalhos podem falhar quando especifica imagens do SO de VMs do Compute Engine (ou personalizadas) com kernels desatualizados. Especificamente, os trabalhos 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 tentar instalar automaticamente os controladores de GPU. Para estas tarefas, também pode resolver as falhas apenas instalando manualmente os controladores da GPU.

Para mais informações sobre GPUs, consulte o artigo Crie e execute uma tarefa que use GPUs.