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.

I log relativi ai timeout non indicano se è stato superato il timeout della task o dell'eseguibile

Quando un job non va a buon fine a causa del superamento di un timeout, i log associati al job non indicano se l'errore è stato causato dal timeout della task o dell'elemento eseguibile pertinente.

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'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 per timeout superato, 50005. Questo log contiene un textPayload simile al seguente messaggio:

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

      Da questo log, registra TASK_INDEX come compito eseguito in modo anomalo, RUNNABLE_INDEX come eseguibile eseguito in modo anomalo 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}\): 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 la task non riuscita, significa che il timeout della task non riuscita è stato superato e ha causato il fallimento.

   • 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, Batch potrebbe ritardare o impedire erroneamente l'esecuzione del job. Nello specifico, Batch richiede ai progetti di avere quote di risorse di Compute Engine sufficienti anche quando queste quote di risorse sono utilizzate da prenotazioni non consumate.

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 delle quote di risorse del progetto prima di tentare di 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. In caso contrario, se i job saltano inutilmente i controlli della quota, potresti visualizzare errori di quota insufficiente non necessari.

Ad esempio, per evitare 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 venga utilizzata dal job.

Per ulteriori istruzioni, consulta Creare ed eseguire un job che può utilizzare VM riservate e Definire 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 le quali 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 di 16 GPU H100.
  • 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, il problema impedisce al progetto di pianificare ed eseguire qualsiasi job configurato correttamente per utilizzare 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 abbia quanto segue:

  • Una quota massima di 16 GPU H100.
  • Una prenotazione per un singolo progetto non utilizzata per 1 VM a3-highgpu-8g, che preleva un totale di 8 GPU H100.
  • Una VM a3-highgpu-8g configurata per non consumare prenotazioni e occasionalmente eliminata e poi ricreata. 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 del sistema operativo della VM Compute Engine che non ha la versione più recente del kernel. Questo problema interessa anche le immagini personalizzate basate sulle immagini del sistema operativo delle VM 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. Valuta invece questo problema se un job non va a buon fine in modo imprevisto e specifica un'immagine del sistema operativo della VM Compute Engine o un'immagine personalizzata simile.

Per evitare o risolvere questo problema, puoi procedere nel seguente modo:

Nota: se il tuo job utilizza le GPU, consulta anche I job che utilizzano GPU e immagini del sistema operativo VM con kernel obsoleti non vanno a buon fine solo quando vengono installati 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 dell'immagine Compute Engine che preferisci. 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 la versione più recente di un'immagine specifica non funziona, potresti dover provare un sistema operativo diverso o creare un'immagine personalizzata. Ad esempio, se la versione più recente di Debian 11 non funziona, puoi provare a creare un'immagine personalizzata da una VM Compute Engine che esegue Debian 11 e che hai aggiornato per utilizzare la versione più recente del kernel.

Questo problema è causato da una versione del kernel obsoleta nell'immagine del sistema operativo della VM che ne causa il riavvio. Quando un job specifica un'immagine del sistema operativo VM non di Batch o basata su un'immagine di 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 delle 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 vengono installati automaticamente i driver

Questo problema è strettamente correlato a I job potrebbero non riuscire se specifichi 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 che utilizzano le GPU potrebbero non riuscire solo se provi a installare i driver GPU automaticamente. Per questi job, puoi 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.