Problèmes connus

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

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

Il est possible que Pub/Sub n'envoie pas de notifications pour les états intermédiaires lors de modifications rapides.

Il est possible que Pub/Sub n'envoie pas de notifications pour tous les états intermédiaires lorsqu'un job ou une tâche change très rapidement. Par exemple, supposons qu'une tâche passe rapidement de l'état ASSIGNED à l'état RUNNING, puis à l'état FAILED. Dans ce cas, il est possible que vous ne receviez pas de notification indiquant que la tâche a atteint l'état RUNNING.

Pour atténuer ce problème, nous vous recommandons, lorsque vous souhaitez consulter l'historique complet des états d'un job ou d'une tâche, d'afficher les événements d'état au lieu des notifications Pub/Sub.

Pour en savoir plus sur les notifications Pub/Sub, consultez Surveiller l'état des jobs à l'aide des notifications Pub/Sub et de BigQuery.

Les journaux de délai 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'un job échoue en raison d'un délai avant expiration dépassé, les journaux associés au job n'indiquent pas si l'échec est dû au délai avant expiration de la tâche concernée ou à celui 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 est dû au dépassement du délai d'expiration de la tâche ou de l'exécutable concerné en suivant la procédure ci-dessous :

1. Identifier la tâche, l'exécutable et l'heure d'un échec de dépassement du délai d'attente.

   1. Affichez les journaux du job.

   2. Recherchez un journal mentionnant le code de sortie de dépassement du délai d'attente, 50005. 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 du dépassement du délai.

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 totale d'exécution 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 du dépassement du délai d'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 d'expiration que vous avez configuré pour la tâche ayant échoué, cela signifie que le délai d'expiration de cette tâche a été dépassé et a entraîné l'échec.

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

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

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 du job 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 de ressources sont utilisés par des réservations non consommé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 de tenter de créer un job.

Important : Il est déconseillé d'activer le libellé goog-batch-skip-quota-check pour les jobs qui ne peuvent consommer aucune réservation dans votre projet. Par exemple, évitez cette solution de contournement si votre projet ne comporte aucune réservation Compute Engine ou si un job nécessite des VM qui ne sont pas compatibles avec ces réservations. Sinon, si les vérifications de quota sont inutilement ignorées par les jobs, vous risquez de rencontrer des échecs pour quota insuffisant inutiles.

Par exemple, pour éviter ou résoudre ce problème pour un job de script de base qui peut 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 le job utilise.

Pour obtenir plus d'instructions, consultez Créer et exécuter un job pouvant consommer des VM réservées et Définir des libellés personnalisés pour le job.

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 l'exécution des tâches qui spécifient ces ressources.

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

  • Un quota maximal de 16 GPU H100.
  • Une réservation à projet unique non consommée pour deux VM a3-highgpu-8g, qui réserve un total de 16 GPU H100.

  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 jobs qui spécifient ces ressources.

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

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

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

Échec possible des jobs lors de la spécification d'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 d'OS de VM Compute Engine qui ne possède pas la dernière version du noyau. Ce problème affecte également toutes les images personnalisées basées sur des images d'OS de VM Compute Engine. Il n'est pas facile d'identifier les images publiques Compute Engine qui causent ce problème, et elles peuvent changer à tout moment.

Ce problème n'est pas indiqué par un message d'erreur spécifique. En revanche, tenez compte de ce problème si vous avez une tâche qui échoue de manière inattendue et qui spécifie une image d'OS de VM Compute Engine ou une image personnalisée similaire.

Pour éviter ou résoudre ce problème, vous pouvez procéder comme suit :

Remarque : Si votre job utilise des GPU, consultez également Les jobs utilisant des GPU et les images d'OS de VM avec des noyaux obsolètes échouent uniquement 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 par lot, 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 l'image Compute Engine de votre choix. En général, les versions plus récentes des images Compute Engine sont plus susceptibles d'avoir 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 noyau.

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 d'OS de VM qui ne provient pas de Batch ni n'est basée sur une image Batch, Batch installe les packages requis sur les VM du job après leur démarrage. Les packages requis peuvent varier selon les jobs et changer au fil du temps. Ils peuvent également nécessiter que l'image de l'OS de votre VM dispose de la dernière version du noyau. Ce problème se produit lorsque 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 du job.

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

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é à Échec possible des jobs 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 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 automatiquement les pilotes de GPU. Pour ces jobs, vous pouvez également résoudre les échecs en installant manuellement les pilotes de GPU.

Pour en savoir plus sur les GPU, consultez Créer et exécuter un job qui utilise des GPU.