Problèmes connus

Cette page décrit les problèmes connus que vous pourriez rencontrer lors de l'utilisation par lot.

Si vous avez besoin d'aide supplémentaire pour utiliser Batch, consultez la dans la documentation de dépannage ou Obtenez de l'aide.

Les journaux d'expiration des délais d'inactivité n'indiquent pas si le délai avant expiration de la tâche ou de l'exécutable a été dépassé

Lorsqu'une tâche échoue en raison du dépassement d'un délai avant expiration : les journaux associés au job n'indiquent pas si le problème est dû au délai avant expiration de la tâche ou du exécutable en question.

Pour contourner ce problème, définissez des valeurs de délai avant expiration différentes pour les tâches et et des exécutables. Ensuite, vous pouvez déterminer si une défaillance a été causée par au-delà du délai avant expiration de la tâche concernée ou de l'exécutable à l'aide des éléments suivants : procédure:

1. Identifier la tâche, l'exécutable et l'heure d'expiration du délai l'échec.

   1. Affichez les journaux relatifs à cette tâche.

   2. Recherchez un journal mentionnant le code de sortie 50005 ayant dépassé le délai d'attente. Ce journal comporte un textPayload semblable au message suivant:

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

      Dans ce journal, enregistrez TASK_INDEX comme la tâche ayant échoué, RUNNABLE_INDEX comme échec de l'exécution, et la valeur timestamp du journal comme heure de l'échec du délai avant expiration.

2. Identifiez l'heure de début de la tâche en échec.

   1. Affichez les événements d'état de la tâche ayant échoué.

   2. Recherchez l'événement d'état mentionnant le message suivant:

      Task state is updated from ASSIGNED to RUNNING
      

      À partir de cet événement d'état, enregistrez le champ eventTime en tant que l'heure de début de la tâche ayant échoué.

3. Calculer la durée d'exécution totale de la tâche ayant échoué, \({failedTaskRunTime}\), en utilisant la formule suivante:

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

   Remplacez les valeurs suivantes :

   • \({failureTime}\): date et heure de l'échec du délai avant expiration.
   • \({failedTaskStartTime}\): heure de début de la tâche ayant échoué.

4. Identifiez le délai avant expiration dépassé:

   • Si \({failedTaskRunTime}\) correspond au délai avant expiration que vous avez configuré la tâche en échec, alors le délai avant expiration de cette tâche en échec a été dépassé et a causé l'échec.

   • Sinon, le délai avant expiration que vous avez configuré pour l'exécutable défaillant a été dépassée et a causé l'échec.

Les jobs utilisant des réservations peuvent être retardés ou empêchés

Lorsque vous essayez de créer et d'exécuter une tâche qui consomme des réservations Compute Engine, Batch peut retarder ou empêcher de manière incorrecte l'exécution de la tâche. Plus précisément, Batch exige que les projets disposent de suffisamment Quotas de ressources de Compute Engine même lorsque ces quotas de ressources sont utilisés par des réservations non consommées.

Solution de contournement du problème

Afin de contourner ce problème pour un job, ajoutez une étiquette avec le paramètre nom goog-batch-skip-quota-check et la valeur true à la champ labels au niveau du poste. Cette étiquette oblige Batch à ignorer la validation les quotas de ressources de votre projet avant de créer un job.

Important :Il est déconseillé d'activer le paramètre Libellé goog-batch-skip-quota-check pour les tâches qui ne peuvent utiliser aucune réservation dans votre projet. Par exemple, évitez cette solution de contournement lorsque votre projet ne comporte aucune réservation Compute Engine ou lorsqu'une tâche nécessite des VM qui ne sont pas compatibles avec ces réservations. Autrement, si les jobs ignorer inutilement les vérifications de quota, vous risquez de voir des images échecs de quotas insuffisants.

Par exemple, pour éviter ou résoudre ce problème de script de base pouvant utiliser des réservations, créer et exécuter un job avec le la configuration JSON suivante:

{
  "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"
  }
}

Remplacez VM_RESOURCES par les ressources de VM qui correspondant à la réservation que le job utilise.

Pour en savoir plus, consultez créer et exécuter un job pouvant consommer des VM réservées ; Définissez des étiquettes personnalisées pour la tâche.

Identifier le problème

Ce problème n'est pas indiqué par un message d'erreur spécifique. Au lieu de cela, cette peut survenir dans les cas suivants:

• Si votre projet réserve toutes les ressources pour lesquelles il dispose d'un quota, ce problème empêche les jobs qui spécifient ces ressources.

  Par exemple, supposons que votre projet comporte les éléments suivants :

  • Quota maximal de 16 GPU H100.
  • Une réservation pour un seul projet non consommée pour 2 VM a3-highgpu-8g ce qui réserve au total 16 GPU H100.

  Dans ce scénario, ce problème empêche votre projet planifier et exécuter toute tâche correctement configurée utilisent l'un des GPU H100 réservés.

• Si votre projet réserve certaines des ressources pour lesquelles il dispose d'un quota, ce problème peut empêcher ou retarder les tâches qui spécifient ces ressources.

  Par exemple, supposons que votre projet comporte les éléments suivants:

  • Un quota maximal de 16 pour les GPU H100
  • Réservation à projet unique non consommée pour une VM a3-highgpu-8g, qui réserve huit GPU H100 au total.
  • Une VM a3-highgpu-8g configurée pour n'utilisent aucune réservation et parfois supprimé, puis recréé. (Cette VM utilise huit GPU H100 non réservés lorsqu'elle existe.)

  Dans ce scénario, ce problème ne permet à votre projet que de planifier et de commencer à exécuter toute tâche correctement configurée pour consommer l'un des GPU H100 réservés lorsque la VM a3-highgpu-8g n'existe pas.

Les tâches peuvent échouer si vous spécifiez des images d'OS de VM Compute Engine (ou personnalisées) avec des noyaux obsolètes

Une tâche peut échouer si elle spécifie une image d'OS de VM Compute Engine qui ne dispose pas de la dernière version du noyau. Ce problème concerne également les images personnalisées basées sur Images d'OS des VM Compute Engine Les images publiques Compute Engine à l'origine de ce problème ne sont pas facilement identifiables et susceptibles d'être modifiées à tout moment.

Ce problème n'est pas indiqué par un message d'erreur spécifique. Envisagez plutôt ce problème si l'un de vos jobs échoue de manière inattendue et spécifie Image de l'OS de la VM Compute Engine ou image personnalisée similaire.

Pour éviter ou résoudre ce problème, procédez comme suit:

Remarque :Si votre tâche utilise des GPU, consultez également Les tâches utilisant des GPU et des images d'OS de VM avec des noyaux obsolètes n'échouent que lors de l'installation automatique des pilotes.

1. Dans la mesure du possible, utilisez des images par lot ou des images personnalisées. basées sur des images Batch, qui ne sont pas concernées par ce problème.
2. Si vous ne pouvez pas utiliser d'image Batch, essayez la dernière version de votre image Compute Engine préférée. Généralement, les plus récentes d'images Compute Engine sont plus susceptibles ont la dernière version de noyau que les anciennes versions.
3. Si la dernière version d'une image spécifique ne fonctionne pas, vous devrez peut-être pour essayer un autre OS ou créer une image personnalisée. Par exemple, si la dernière version de Debian 11 ne fonctionne pas, vous pouvez essayer de créer une image personnalisée à partir d'une VM Compute Engine exécutant Debian 11 et que vous avez mise à jour pour utiliser la dernière version du kernel.

Ce problème est causé par une version de noyau obsolète dans le Image d'OS de VM qui entraîne le redémarrage de la VM. Lorsqu'une tâche spécifie Image d'OS de VM qui ne provient pas de Batch ou qui est basée sur un Image Batch, installations par lot sur les VM du job après leur démarrage. Packages requis peuvent varier selon les emplois et évoluer au fil du temps, et peuvent nécessiter l'image de l'OS de votre VM afin de disposer de la dernière version du noyau. Ce problème apparaît lors de la mise à jour de la version du noyau nécessite que la VM redémarre, ce qui entraîne l'installation du package et le job échoue.

Pour en savoir plus sur les images d'OS de VM, consultez Présentation de l'environnement de système d'exploitation pour les VM d'un job

Les tâches utilisant des GPU et des images d'OS de VM avec des noyaux obsolètes ne peuvent échouer que lors de l'installation automatique des pilotes.

Ce problème est étroitement lié à Les tâches peuvent échouer si vous spécifiez des images d'OS de VM Compute Engine (ou personnalisées) avec des noyaux obsolètes. Plus précisément, les jobs qui spécifient Image de l'OS de VM Compute Engine (ou personnalisée) sans le dernier noyau et l'utilisation de GPU ne peuvent échouer que si vous essayez d'installer des pilotes de GPU. automatiquement. Pour ces jobs, vous pouvez également résoudre les échecs installer manuellement les pilotes de GPU.

Pour en savoir plus sur les GPU, consultez Créez et exécutez une tâche qui utilise des GPU.