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 contactez l'assistance.

Les journaux des délais avant expiration 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 du délai avant expiration, les journaux associés à la tâche n'indiquent pas si l'échec est dû au délai avant expiration de la tâche concernée ou 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 d'inactivité de la tâche concernée ou de l'exécutable en procédant comme suit:

1. Identifiez la tâche, l'exécutable et l'heure d'un échec du délai avant expiration dépassé.

   1. Affichez les journaux de la tâche.

   2. Recherchez un journal mentionnant le code de sortie 50005 qui a expiré. 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 en tant que tâche ayant échoué, RUNNABLE_INDEX comme exécutable ayant échoué et la valeur timestamp du journal en tant qu'heure d'é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. Calculez la durée totale d'exécution de la tâche en échec, \({failedTaskRunTime}\), à l'aide de la formule suivante:

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

   Remplacez les valeurs suivantes :

   • \({failureTime}\): heure d'échec du 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'inactivité que vous avez configuré pour la tâche ayant échoué, celui-ci a été dépassé et a causé l'échec.

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

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

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

Résoudre le problème

Pour contourner ce problème pour une tâche, ajoutez une étiquette dont le nom est goog-batch-skip-quota-check et la valeur true dans le champ labels au niveau de la tâche. Ce libellé empêche Batch d'ignorer la vérification des quotas de ressources de votre projet avant de tenter de créer un job.

Important :Il n'est pas recommandé d'activer le libellé goog-batch-skip-quota-check pour les tâches qui ne peuvent consommer 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 non compatibles avec ces réservations. Dans le cas contraire, si des 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 concernant une tâche de script de base pouvant consommer des réservations, créez et exécutez une tâche 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 utiliser pour le job.

Pour en savoir plus, consultez les sections Créer et exécuter une tâche pouvant consommer des VM réservées et Définir des étiquettes personnalisées pour la tâche.

Identifier le problème

Ce problème n'est signalé par aucun message d'erreur spécifique. Ce problème 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 toute tâche spécifiant ces ressources.

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

  • Un quota maximal de 16 pour les GPU H100.
  • Réservation d'un seul projet non utilisée pour deux VM a3-highgpu-8g, qui réserve au total 16 GPU H100.

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

• Si votre projet réserve certaines 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 à un seul projet non utilisée pour 1 VM a3-highgpu-8g, ce qui réserve 8 GPU H100 au total.
  • Une VM a3-highgpu-8g configurée pour ne consommer aucune réservation et qui est parfois supprimée, puis recréée. (Cette VM utilise huit GPU H100 non réservés, le cas échéant.)

  Dans ce scénario, ce problème ne permet à votre projet de planifier et de démarrer une tâche que si elle est correctement configurée pour utiliser 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

Un job peut échouer s'il spécifie une image de l'OS de VM Compute Engine qui ne dispose pas de la dernière version du noyau. Ce problème affecte également les images personnalisées basées sur des images de l'OS de VM Compute Engine. Les images publiques Compute Engine à l'origine de ce problème ne sont pas facilement identifiées et peuvent être modifiées à tout moment.

Ce problème n'est pas indiqué par un message d'erreur spécifique. Considérez plutôt ce problème si l'une de vos tâches échoue de manière inattendue et spécifie une image de l'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 n'échouent que lors de l'installation automatique de pilotes.

1. Dans la mesure du possible, utilisez des images par lot ou des images personnalisées basées sur des images par 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 votre image Compute Engine préférée. En règle générale, les versions plus récentes des images Compute Engine sont plus susceptibles de posséder la dernière version de noyau que les anciennes.
3. Si la dernière version d'une image spécifique ne fonctionne pas, vous devrez peut-être essayer un autre système d'exploitation 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 afin d'utiliser la dernière version du noyau.

Ce problème est dû à une version de noyau obsolète dans l'image de l'OS de la VM, qui entraîne le redémarrage de la VM. Lorsqu'une tâche spécifie une image de l'OS de VM qui ne provient pas de Batch ou qui est basée sur une image Batch, Batch installe les packages requis sur les VM de la tâche après leur démarrage. Les packages requis peuvent varier pour différentes tâches et changer au fil du temps. Ils peuvent également nécessiter que votre image de l'OS de VM dispose de la dernière version du noyau. Ce problème survient lors de la mise à jour de la version du noyau 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 la section Présentation de l'environnement d'OS pour les VM d'une tâche.

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

Ce problème est étroitement lié à la section Les tâches 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 peuvent échouer uniquement si vous essayez d'installer des pilotes de GPU automatiquement. Pour ces tâches, vous pouvez également résoudre les défaillances en installant manuellement les pilotes de GPU.

Pour en savoir plus sur les GPU, consultez la page Créer et exécuter une tâche qui utilise des GPU.