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 relativa alla 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 lo stato di un'attività cambi rapidamente da ASSIGNED a RUNNING e poi a FAILED. In questo scenario, potresti non ricevere una notifica che ti avvisa che l'attività ha raggiunto lo stato RUNNING.

Per risolvere 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 del job utilizzando le notifiche Pub/Sub e BigQuery.

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

Quando un job non viene eseguito 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 da quello del runnable pertinente.

Per risolvere il problema, imposta valori di timeout diversi per attività e runnable. Dopodiché, puoi identificare se un errore è stato causato dal superamento del timeout dell'attività o del runnable pertinente utilizzando la seguente procedura:

  1. Identifica l'attività, il runnable 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 exceeded-timeout, 50005. Questo log ha 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 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

      Da questo 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 di quest'ultima è stato superato e ha causato l'errore.

    • In caso contrario, il timeout configurato per il runnable non riuscito è 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 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 Compute Engine sufficienti anche quando queste quote di risorse vengono utilizzate da prenotazioni non consumate.

Scopri di più su questo problema:

  1. Se vuoi saperne di più su come e quando questo problema influisce sui job, consulta Identificare e comprendere questo problema.
  2. Per scoprire come prevenire o risolvere il problema, consulta Soluzione alternativa al problema.

Identificare e comprendere il problema

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

  • Se il tuo progetto riserva tutte le risorse per le quali è prevista 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, questo problema impedisce al tuo progetto di pianificare ed eseguire qualsiasi job configurato correttamente per utilizzare una delle 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 riserva un totale di 8 GPU H100.
    • Una VM a3-highgpu-8g configurata per non utilizzare prenotazioni e che viene eliminata e ricreata occasionalmente. 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 quando la VM a3-highgpu-8g non esiste.

Soluzione alternativa

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 tuo progetto prima di tentare di creare un job.

Ad esempio, per prevenire 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 Crea ed esegui un job che può utilizzare le VM riservate e Definisci etichette personalizzate per il job.

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

Un job potrebbe non riuscire se specifica un'immagine sistema operativo VM Compute Engine che non ha l'ultima versione kernel. Questo problema interessa anche le immagini personalizzate basate sulle immagini del sistema operativo delle VM Compute Engine. Tieni presente questo problema se hai un job che non va a buon fine in modo imprevisto e specifica un'immagine sistema operativo VM Compute Engine o un'immagine personalizzata simile. Sebbene questo problema possa verificarsi per qualsiasi immagine Compute Engine (anche l'ultima versione) in qualsiasi momento, abbiamo osservato che si verifica principalmente per le immagini Compute Engine Debian.

Scopri di più su questo problema:

  1. Se vuoi saperne di più su come e quando questo problema influisce sui job, consulta Identificare e comprendere questo problema.
  2. Per scoprire come prevenire o risolvere il problema, consulta Soluzione alternativa al problema.

Identificare e comprendere il problema

Questo problema è causato da una versione kernel obsoleta nell'immagine 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 lavori diversi e cambiare nel tempo e potrebbero richiedere che l'immagine del sistema operativo della 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'installazione del pacchetto e l'errore del job.

Questo problema può verificarsi in qualsiasi momento, anche se utilizzi l'ultima versione di un'immagine Compute Engine. Se un sistema operativo è stato aggiornato di recente, soprattutto per aggiornamenti imprevedibili come hotfix (aggiornamenti urgenti per vulnerabilità o problemi critici), le immagini del sistema operativo VM di Compute Engine potrebbero non essere ancora in grado di reagire alle modifiche. Ad esempio, abbiamo osservato che, per il sistema operativo Debian, i pacchetti con prefissi linux-headers- possono essere rimossi in modo imprevedibile dal kernel tramite hotfix.

Per identificare questo problema, ti consigliamo di visualizzare i log del job per verificare la presenza di errori di installazione relativi all'immagine del sistema operativo della VM. Ad esempio, se il tuo job utilizza un'immagine Compute Engine Debian o un'immagine personalizzata simile, ti consigliamo di verificare la presenza di errori relativi all'installazione dei pacchetti linux-headers- specificando la seguente query:

labels.job_uid="JOB_UID" AND severity="ERROR" AND textPayload:("failed" "apt" "install" "linux-headers-")

Sostituisci JOB_UID con l'ID univoco (UID) del job. Per ottenere l'UID di un job, descrivi il job. Se questa query restituisce risultati, questo problema potrebbe influire sul tuo job.

Soluzione alternativa

Per prevenire o risolvere il problema, ti consigliamo di procedere nel seguente modo:

  1. Se possibile, utilizza immagini batch o immagini personalizzate basate su immagini batch, che non sono interessate da questo problema.

  2. Prova l'ultima versione dell'immagine Compute Engine che preferisci. In genere, le versioni più recenti delle immagini Compute Engine hanno più probabilità di avere la versione kernel più recente rispetto alle versioni precedenti.

  3. Scegli una delle seguenti opzioni:

    • Prova un altro sistema operativo o crea un'immagine personalizzata. Ad esempio, se l'ultima versione di Debian 12 non funziona, puoi provare a creare un'immagine personalizzata da una VM di Compute Engine che esegue Debian 12 e che hai aggiornato per utilizzare l'ultima versione kernel.

    • Se il job non va a buon fine a causa di errori relativi all'installazione dei pacchetti linux-headers-, puoi provare a utilizzare l'immagine del sistema operativo VM con pacchetti linux-headers- obsoleti. Per consentire i pacchetti linux-headers- obsoleti, aggiungi un'etichetta con il nome goog-batch-allow-insecure-linux-headers-installation e il valore true al campo labels a livello di job.

      Ad esempio, per consentire pacchetti linux-headers- obsoleti per un job di script di base che specifica un'immagine del sistema operativo VM, 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": [
      {
        "policy": {
          "bootDisk": {
            "image": "VM_OS_IMAGE_URI"
          }
        }
      }
    ]
  },
  "labels": {
    "goog-batch-allow-insecure-linux-headers-installation": "true"
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

      Sostituisci VM_OS_IMAGE_URI con l'URI dell'immagine del sistema operativo della VM che vuoi utilizzare.

      Per ulteriori istruzioni, vedi Definisci etichette personalizzate per il job e Specifica l'immagine del sistema operativo della VM per un job.

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

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

Questo problema è strettamente correlato al precedente, I job potrebbero non riuscire quando si specificano immagini del sistema operativo VM di 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 GPU potrebbero non riuscire solo se tenti di installare automaticamente i driver GPU. Per questi job, potresti risolvere gli errori anche semplicemente installando manualmente i driver GPU.

Per ulteriori informazioni su questo problema e su come risolverlo, vedi I job potrebbero non riuscire quando vengono specificate immagini del sistema operativo VM Compute Engine (o personalizzate) con kernel obsoleti. Per saperne di più sulle GPU, consulta Crea ed esegui un job che utilizza le GPU.