Problèmes connus

Cette page décrit les problèmes connus que vous pouvez rencontrer lors de l'utilisation de Batch.

Si vous avez besoin d'aide supplémentaire pour utiliser Batch, consultez la documentation de dépannage ou demandez 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'un job échoue en raison du dépassement d'un délai avant expiration, les journaux associés au job n'indiquent pas si l'échec a été causé par le délai avant expiration de la tâche concernée ou par le délai avant expiration de l'exécutable concerné.

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. Identifiez la tâche, l'exécutable et l'heure d'un échec de délai avant expiration dépassé.

   1. Affichez les journaux de la tâche.

   2. Recherchez un journal qui mentionne le code de sortie 50005, qui indique que le délai avant expiration a été dépassé. Ce journal contient 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 ayant échoué.

   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 comme 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é la défaillance.

   • 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 exécuter un job qui consomme des réservations Compute Engine Batch peut retarder ou empêcher à tort le job en cours d'exécution. Plus précisément, Batch exige que les projets disposent de quotas de ressources Compute Engine suffisants, même si ces quotas de ressources sont utilisés par des réservations inutilisées.

Contourner le 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. Ce libellé permet à Batch d'ignorer la vérification des quotas de ressources de votre projet avant d'essayer de créer une tâche.

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 des réservations Compute Engine ou lorsqu'un job nécessite des VM qui ne sont pas compatibles avec ces réservations. Sinon, si les tâches ignorent inutilement les vérifications des quotas, vous risquez de constater des échecs de quota insuffisants inutiles.

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 les pages Créer et exécuter une tâche pouvant consommer des VM réservées et Définir des libellés personnalisés pour la tâche.

Identifier le problème

Aucun message d'erreur spécifique n'indique ce problème. Ce problème peut se produire dans les circonstances suivantes :

• 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 à projet unique non consommée pour deux VM a3-highgpu-8g, qui réserve 16 GPU H100 au total.

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

• Si votre projet réserve certaines des ressources pour lesquelles il dispose d'un quota, peut empêcher ou retarder 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 à un seul projet non consommée pour 1 VM a3-highgpu-8g, qui réserve 8 GPU H100 au total.
  • VM a3-highgpu-8g configurée pour ne pas utiliser de réservations et supprimée de temps en temps, puis recréée. (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 lorsque 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 kernel. 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 faciles à identifier et peuvent ê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 une tâche échoue de manière inattendue et spécifie une image d'OS de VM Compute Engine ou une 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 ne plantent que lors de l'installation automatique des pilotes.

1. Dans la mesure du possible, utilisez des images de lot ou des images personnalisées basées sur des images de lot, qui ne sont pas affectées par ce problème.
2. Si vous ne pouvez pas utiliser d'image Batch, essayez la dernière version de l'image Compute Engine de votre choix. 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 dû à une version obsolète du noyau dans l'image de l'OS de la VM, ce qui entraîne le redémarrage de la VM. Lorsqu'une tâche spécifie une image de système d'exploitation de VM qui ne provient pas de Batch ou qui n'est pas basée sur une image de Batch, Batch installe les paquets requis sur les VM de la tâche après leur démarrage. Les paquets requis peuvent varier selon les tâches et changer au fil du temps. Ils peuvent nécessiter que l'image de l'OS de votre VM dispose de la dernière version du kernel. Ce problème se produit lorsque la mise à jour de la version du kernel nécessite le redémarrage de la VM, ce qui entraîne l'échec de l'installation du package et de la tâche.

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 peuvent échouer uniquement lors de l'installation automatique des pilotes.

Ce problème est étroitement lié à Les jobs peuvent échouer lors de la spécification d'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 tâches, vous pouvez également résoudre les échecs en installant 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.