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 n'indiquent pas si le délai d'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 les exécutables. Vous pouvez ensuite déterminer si un échec a été causé par le dépassement du délai avant expiration de la tâche ou de l'exécutable concerné en procédant comme suit:

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
      

      À partir de ce journal, enregistrez TASK_INDEX comme tâche ayant échoué, RUNNABLE_INDEX comme exécutable ayant échoué et la valeur timestamp du journal comme heure de l'échec dû à un dépassement 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 qui mentionne 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. Calculez la durée d'exécution totale de la tâche ayant échoué, \({failedTaskRunTime}\), à l'aide de la formule suivante:

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

   Remplacez les valeurs suivantes :

   • \({failureTime}\): heure de l'échec dû à un délai avant expiration dépassé.
   • \({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 d'expiration que vous avez configuré pour la tâche ayant échoué, le délai d'expiration de cette tâche ayant échoué a été dépassé et a causé l'échec.

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

Les tâches qui consomment des réservations peuvent être retardées ou empêchées.

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 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

Pour contourner ce problème pour une tâche, ajoutez un libellé avec le nom goog-batch-skip-quota-check et la valeur true au champ labels au niveau de la tâche. 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 l'étiquette goog-batch-skip-quota-check pour les tâches qui ne peuvent pas consommer de réservations 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. Sinon, si les tâches ignorent inutilement les vérifications de quota, vous risquez de constater des échecs de quota insuffisants inutiles.

Par exemple, pour éviter ou résoudre ce problème pour un job de script de base pouvant consommer des réservations, créez et exécutez un job avec 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 correspondant à la réservation que vous souhaitez que la tâche 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 toutes les tâches qui spécifient ces ressources.

  Par exemple, imaginons 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, ce problème peut empêcher ou retarder les tâches qui spécifient ces ressources.

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

  • Quota maximal de 16 GPU H100.
  • Réservation à projet unique non consommée pour une VM a3-highgpu-8g, qui réserve huit 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 jobs 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 affecte également toutes les images personnalisées basées sur des images d'OS de 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.

Aucun message d'erreur spécifique n'indique ce problème. 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 la section 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. En général, les versions plus récentes des images Compute Engine sont plus susceptibles de disposer de la dernière version du noyau que les versions plus anciennes.
3. Si la dernière version d'une image spécifique ne fonctionne pas, vous devrez peut-être 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'un job 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 du job 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 de l'OS de la VM, consultez la section Présentation de l'environnement d'OS des VM d'une tâche.

Les jobs 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 tâches qui spécifient à la fois une image d'OS de VM Compute Engine (ou personnalisée) sans le dernier noyau et qui utilisent des GPU ne peuvent échouer que si vous essayez d'installer automatiquement les pilotes de GPU. 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 la section Créer et exécuter une tâche qui utilise des GPU.