Problemi noti

Questa pagina descrive i problemi noti che potresti riscontrare durante l'utilizzo di Batch.

Se hai bisogno di ulteriore assistenza per l'utilizzo di Batch, consulta la documentazione sulla risoluzione dei problemi o richiedi assistenza.

Pub/Sub potrebbe non inviare notifiche per gli stati intermedi durante le modifiche rapide

Pub/Sub potrebbe non inviare notifiche per tutti gli stati intermedi quando un job o un'attività cambia molto rapidamente. Ad esempio, supponiamo che un'attività cambi rapidamente stato da ASSIGNED, poi RUNNING e infine FAILED. In questo scenario, potresti non ricevere una notifica che indica che l'attività ha raggiunto lo stato RUNNING.

Per attenuare questo problema, ti consigliamo di visualizzare gli eventi di stato anziché le notifiche Pub/Sub quando vuoi visualizzare la cronologia completa dello stato di un job o di un'attività.

Per ulteriori informazioni sulle notifiche Pub/Sub, consulta Monitorare lo stato dei job utilizzando le notifiche Pub/Sub e BigQuery.

I log dei timeout non indicano se è stato superato il timeout dell'attività o dell'eseguibile

Quando un job non riesce a causa del superamento di un timeout, i log associati al job non indicano se l'errore è stato causato dal timeout dell'attività pertinente o dal timeout dell'eseguibile pertinente.

Per risolvere questo problema, imposta valori di timeout diversi per attività ed eseguibili. Poi, puoi identificare se un errore è stato causato dal superamento del timeout dell'attività o dell'eseguibile pertinente utilizzando la seguente procedura:

  1. Identifica l'attività, l'eseguibile e l'ora di un errore di timeout superato.

    1. Visualizza i log del job.

    2. Trova un log che menzioni il codice di uscita del timeout superato, 50005. Questo log ha un textPayload simile al seguente messaggio:

      Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005

      Dal log, registra TASK_INDEX come attività non riuscita, RUNNABLE_INDEX come eseguibile non riuscito e il valore timestamp del log come ora dell'errore di timeout superato.

  2. Identifica l'ora di inizio dell'attività non riuscita.

    1. Visualizza gli eventi di stato dell'attività non riuscita.

    2. Trova l'evento di stato che menziona il seguente messaggio:

      Task state is updated from ASSIGNED to RUNNING

      Dall'evento di stato, registra il campo eventTime come ora di inizio dell'attività non riuscita.

  3. Calcola il tempo di esecuzione totale dell'attività non riuscita, \({failedTaskRunTime}\), utilizzando la seguente formula:

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

    Sostituisci i seguenti valori:

    • \({failureTime}\): l'ora dell'errore di timeout superato.
    • \({failedTaskStartTime}\): l'ora di inizio dell'attività non riuscita.

  4. Identifica il timeout superato:

    • Se \({failedTaskRunTime}\) corrisponde al timeout configurato per l'attività non riuscita, il timeout dell'attività non riuscita è stato superato e ha causato l'errore.

    • In caso contrario, il timeout configurato per l'eseguibile non riuscito è stato superato e ha causato l'errore.

I job che utilizzano le prenotazioni potrebbero essere ritardati o impediti

Quando provi a creare ed eseguire un job che utilizza le prenotazioni di Compute Engine, Batch potrebbe ritardare o impedire erroneamente l'esecuzione del job. In particolare, Batch richiede che i progetti dispongano di quote di risorse di Compute Engine sufficienti anche quando queste quote di risorse vengono utilizzate da prenotazioni non utilizzate.

Soluzione alternativa al problema

Per risolvere questo problema per un job, aggiungi un'etichetta con il nome goog-batch-skip-quota-check e il valore true al campo labels a livello di job. Questa etichetta fa sì che Batch salti la verifica delle quote di risorse del progetto prima di provare a creare un job.

Ad esempio, per impedire o risolvere questo problema per un job di script di base che può utilizzare le prenotazioni, crea ed esegui un job con la seguente configurazione JSON:

{
  "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"
  }
}

Sostituisci VM_RESOURCES con le risorse VM che corrispondono alla prenotazione che vuoi che il job utilizzi.

Per ulteriori istruzioni, consulta Creare ed eseguire un job che può utilizzare le VM riservate e Definire etichette personalizzate per il job.

Identificare il problema

Questo problema non è indicato da alcun messaggio di errore specifico. Al contrario, questo problema può verificarsi nelle seguenti circostanze:

  • Se il tuo progetto riserva tutte le risorse per cui ha una quota, questo problema impedisce l'esecuzione di qualsiasi job che specifichi queste risorse.

    Ad esempio, supponiamo che il tuo progetto abbia quanto segue:

    • Una quota massima per le GPU H100 di 16.
    • Una prenotazione per un singolo progetto non utilizzata per 2 VM a3-highgpu-8g, che riserva un totale di 16 GPU H100.

    In questo scenario, questo problema impedisce al tuo progetto di pianificare ed eseguire qualsiasi job configurato correttamente per utilizzare una qualsiasi delle GPU H100 riservate.

  • Se il tuo progetto riserva alcune delle risorse per cui ha una quota, questo problema potrebbe impedire o ritardare i job che specificano queste risorse.

    Ad esempio, supponiamo che il tuo progetto abbia quanto segue:

    • Una quota massima per le GPU H100 di 16.
    • Una prenotazione per un singolo progetto non utilizzata per 1 VM a3-highgpu-8g, che riserva un totale di 8 GPU H100.
    • Una VM a3-highgpu-8g configurata in modo da non utilizzare alcuna prenotazione e che viene occasionalmente eliminata e poi ricreata. (Questa VM utilizza 8 GPU H100 non riservate quando esiste.)

    In questo scenario, questo problema consente al tuo progetto di pianificare e avviare l'esecuzione di qualsiasi job configurato correttamente per utilizzare una qualsiasi delle GPU H100 riservate solo quando la VM a3-highgpu-8g non esiste.

I job potrebbero non riuscire quando si specificano immagini del sistema operativo VM Compute Engine (o personalizzate) con kernel obsoleti

Un job potrebbe non riuscire se specifica un'immagine del sistema operativo VM Compute Engine che non ha la versione kernel più recente. Questo problema riguarda anche le immagini personalizzate basate su immagini del sistema operativo VM Compute Engine. Le immagini pubbliche di Compute Engine che causano questo problema non sono facilmente identificabili e possono essere modificate in qualsiasi momento.

Questo problema non è indicato da un messaggio di errore specifico. Al contrario, considera questo problema se hai un job che non riesce in modo imprevisto e specifica un'immagine del sistema operativo VM Compute Engine o un'immagine personalizzata simile.

Per impedire o risolvere questo problema, puoi procedere come segue:

  1. Quando possibile, utilizza le immagini Batch o le immagini personalizzate basate su immagini Batch, che non sono interessate da questo problema.
  2. Se non puoi utilizzare un'immagine Batch, prova l'ultima versione dell'immagine Compute Engine che preferisci. In genere, le versioni più recenti delle immagini Compute Engine hanno maggiori probabilità di avere la versione kernel più recente rispetto alle versioni precedenti.
  3. Se l'ultima versione di un'immagine specifica non funziona, potrebbe essere necessario provare un altro sistema operativo o creare un'immagine personalizzata. Ad esempio, se l'ultima versione di Debian 12 non funziona, puoi provare a creare un'immagine personalizzata da una VM Compute Engine che esegue Debian 12 e che hai aggiornato per utilizzare la versione kernel più recente.

Questo problema è causato da una versione kernel obsoleta nell'immagine del sistema operativo VM che causa il riavvio della VM. Quando un job specifica un'immagine del sistema operativo VM che non proviene da Batch o non è basata su un'immagine Batch, Batch installa i pacchetti richiesti sulle VM del job dopo l'avvio. I pacchetti richiesti possono variare per job diversi e cambiare nel tempo e potrebbero richiedere che l'immagine del sistema operativo VM abbia la versione kernel più recente. Questo problema si verifica quando l'aggiornamento della versione kernel richiede il riavvio della VM, il che causa l'errore dell'installazione del pacchetto e del job.

Per ulteriori informazioni sulle immagini del sistema operativo VM, consulta Panoramica dell'ambiente del sistema operativo per le VM di un job.

I job che utilizzano le GPU e le immagini del sistema operativo VM con kernel obsoleti potrebbero non riuscire solo durante l'installazione automatica dei driver

Questo problema è strettamente correlato a I job potrebbero non riuscire quando si specificano immagini del sistema operativo VM Compute Engine (o personalizzate) con kernel obsoleti. In particolare, i job che specificano un'immagine del sistema operativo VM Compute Engine (o personalizzata) senza il kernel più recente e utilizzano le GPU potrebbero non riuscire solo se provi a installare automaticamente i driver GPU. Per questi job, potresti anche risolvere gli errori semplicemente installando manualmente i driver GPU.

Per ulteriori informazioni sulle GPU, consulta Creare ed eseguire un job che utilizza le GPU.