Problemi noti

In questa pagina vengono descritti i problemi noti che potresti riscontrare durante l'utilizzo Batch.

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

I log relativi ai timeout non indicano se è stato superato il timeout della task 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 del timeout della pertinente eseguibile.

Per risolvere il problema, imposta valori di timeout diversi per le attività e i programmabili. A questo punto, puoi capire se un errore è stato causato dall'exceeding del timeout dell'attività o dell'elemento eseguibile pertinente utilizzando la seguente procedura:

1. Identifica l'attività, l'esecuzione e il tempo di timeout superato errore.

   1. Visualizza i log per il job.

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

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

      Nel log, registra TASK_INDEX come attività non riuscita, RUNNABLE_INDEX come non riuscita 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
      

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

3. Calcola il tempo di esecuzione totale della task non riuscita, \({failedTaskRunTime}\), utilizzando la seguente formula:

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

   Sostituisci i seguenti valori:

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

4. Identifica il timeout superato:

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

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

I job che utilizzano le prenotazioni potrebbero subire ritardi o essere impediti

Quando provi a creare ed eseguire un job che utilizza prenotazioni Compute Engine, Il batch potrebbe ritardare o impedire in modo errato il job in esecuzione. Nello specifico, Batch richiede che i progetti abbiano sufficienti Quote delle risorse Compute Engine anche quando le quote delle risorse sono utilizzate da prenotazioni non utilizzate.

Soluzione alternativa al problema

Per risolvere il 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 le quote delle risorse del progetto prima di provare a creare un job.

Importante: non è consigliabile attivare l'etichetta goog-batch-skip-quota-check per i job che non possono utilizzare prenotazioni nel progetto. Ad esempio, evita questa soluzione alternativa se il tuo progetto non ha prenotazioni Compute Engine o se un job richiede VM non compatibili con queste prenotazioni. Altrimenti, se i job saltare i controlli della quota inutilmente, potresti vedere errori di quota insufficienti.

Ad esempio, per prevenire o risolvere il problema per una un job di script di base che può consumare prenotazioni, creare ed eseguire 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 la prenotazione che deve essere utilizzata dal job.

Per ulteriori istruzioni, vedi Crea ed esegui un job che può utilizzare VM prenotate e Definisci le etichette personalizzate per il job.

Identificare il problema

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

• Se il progetto riserva tutte le risorse per cui è disponibile la quota, questo problema impedisce qualsiasi job che specifica queste risorse.

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

  • Una quota massima per GPU H100 di 16.
  • Una prenotazione di 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 progetto pianificare ed eseguire qualsiasi job configurato correttamente e consumano tutte le GPU H100 riservate.

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

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

  • Una quota massima per GPU H100 di 16.
  • Una prenotazione di un singolo progetto non utilizzata per 1 VM a3-highgpu-8g, che prenota un totale di 8 GPU H100.
  • Una VM a3-highgpu-8g configurata su senza consumare prenotazioni e che occasionalmente viene eliminato e poi ricreato. Questa VM utilizza 8 GPU H100 non riservate, se esistenti.

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

I job potrebbero non riuscire se specifichi immagini del sistema operativo VM Compute Engine (o personalizzate) con kernel obsoleti

Un job potrebbe non riuscire se specifica un'immagine sistema operativo VM di Compute Engine che non ha l'ultima versione del kernel. Questo problema interessa anche le immagini personalizzate basate sulle immagini del sistema operativo VM di Compute Engine. Le immagini pubbliche di Compute Engine che causano questo problema non sono facilmente identificabili e sono soggette a modifiche in qualsiasi momento.

Questo problema non è indicato da un messaggio di errore specifico. Prendi in considerazione invece questo problema se hai un job che non riesce in modo imprevisto e specifica un Immagine sistema operativo VM di Compute Engine o immagine personalizzata simile.

Per prevenire o risolvere il problema, puoi procedere come segue:

Nota: se il tuo job utilizza GPU, consulta anche I job che utilizzano GPU e immagini del sistema operativo VM con kernel obsoleti non vanno a buon fine solo quando si installano automaticamente i driver.

1. Se possibile, utilizza immagini batch o personalizzate basate su immagini batch, che non sono interessate da questo problema.
2. Se non riesci a utilizzare un'immagine di batch, prova la versione più recente della tua immagine Compute Engine preferita. In genere, le versioni più recenti delle immagini Compute Engine hanno maggiori probabilità di avere la versione più recente del kernel rispetto alle versioni precedenti.
3. Se l'ultima versione di un'immagine specifica non funziona, potresti aver bisogno per provare un sistema operativo diverso o creare un'immagine personalizzata. Ad esempio, se l'ultima versione di Debian 11 non funziona, puoi provare a crea un'immagine personalizzata da un VM di Compute Engine che esegue Debian 11 e che hai aggiornato per usare l'ultima versione del kernel.

Questo problema è causato da una versione del kernel obsoleta nella Immagine del sistema operativo della 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 della VM abbia la versione più recente del kernel. Questo problema si verifica quando l'aggiornamento della versione del kernel richiede il riavvio della VM, causando il fallimento dell'installazione del pacchetto e del job.

Per saperne di più sulle immagini del sistema operativo VM, consulta Panoramica dell'ambiente del sistema operativo per le VM di un job.

I job che utilizzano GPU e immagini del sistema operativo VM con kernel obsoleti potrebbero non riuscire solo quando si installano automaticamente i driver

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

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