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 Résoudre les problèmes ou Obtenir de l'aide.

Pub/Sub n'envoie peut-être pas de notifications pour les états intermédiaires lors de changements rapides

Pub/Sub n'envoie peut-être 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 à RUNNING, puis à FAILED. Dans ce scénario, vous ne recevrez peut-être pas de notification indiquant que la tâche a atteint l'état RUNNING.

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

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, 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 pourrez ensuite déterminer si un échec est dû au 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 du job.

    2. Recherchez un journal qui mentionne le code de sortie de délai avant expiration dépassé, 50005. 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 tâche ayant échoué, RUNNABLE_INDEX comme exécutable ayant échoué et la valeur timestamp du journal comme heure de l'échec de délai avant expiration dépassé.

  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

      Dans 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 de 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 avant expiration que vous avez configuré pour la tâche ayant échoué, cela signifie que le délai avant expiration de cette tâche a été dépassé et a provoqué 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 jobs qui consomment des réservations peuvent être retardés ou empêché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 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 un job, ajoutez un libellé avec le nom goog-batch-skip-quota-check et la valeur true au champ labels au niveau du job. Ce libellé permet à Batch d'ignorer la vérification des quotas de ressources de votre projet avant de tenter de créer un job.

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 qui correspondent à la réservation que vous souhaitez que le job consomme.

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

Identifier le problème

Ce problème n'est indiqué par aucun message d'erreur spécifique. Il 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 tous les jobs qui spécifient ces ressources.

    Supposons, par exemple, que votre projet présente les caractéristiques suivantes :

    • Un 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 tout job correctement configuré 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.

    Supposons, par exemple, que votre projet présente les caractéristiques suivantes :

    • Un quota maximal de 16 GPU H100.
    • Une réservation à projet unique non consommée pour une VM a3-highgpu-8g, 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 8 GPU H100 non réservés lorsqu'elle existe.)

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

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

Un job peut échouer s'il spécifie une image d'OS de VM Compute Engine qui ne dispose pas de 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. Les images publiques Compute Engine qui provoquent ce problème ne sont pas facilement identifiables et peuvent être modifiées à tout moment.

Ce problème n'est indiqué par aucun message d'erreur spécifique. Tenez plutôt compte de ce problème si vous avez un job 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 :

  1. Dans la mesure du possible, utilisez des images Batch ou des images personnalisées basées sur des images Batch, 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 règle générale, 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 12 ne fonctionne pas, vous pouvez essayer de créer une image personnalisée à partir d'une VM Compute Engine qui exécute Debian 12 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 d'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 ou qui n'est pas 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 d'un job à l'autre et changer au fil du temps. Ils peuvent nécessiter que votre image d'OS de 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 d'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é à 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 à 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 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.