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 indica 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 questo problema, imposta valori di timeout diversi per le attività e i runnable. Quindi, puoi identificare se un errore è stato causato dal superamento del timeout dell'attività o del runnable pertinente utilizzando la seguente procedura:
Identifica l'attività, il runnable e l'ora di un errore di timeout superato.
Trova un log che menzioni il codice di uscita exceeded-timeout,
50005
. Questo log ha untextPayload
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 valoretimestamp
del log come ora dell'errore di timeout superato.
Identifica l'ora di inizio dell'attività non riuscita.
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.
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.
Identifica il timeout superato:
Se \({failedTaskRunTime}\) corrisponde al timeout configurato per l'attività non riuscita, il timeout di questa attività è 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 l'esecuzione del job in modo errato. Nello specifico, 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.
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 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.
Identificare 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 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 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 una VM
a3-highgpu-8g
, che riserva un totale di 8 GPU H100. - Una VM
a3-highgpu-8g
configurata per non utilizzare alcuna prenotazione e che viene eliminata e ricreata occasionalmente. (Questa VM utilizza 8 GPU H100 non riservate quando esiste.)
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 quando la VM
a3-highgpu-8g
non esiste.
I job potrebbero non riuscire quando vengono specificate immagini del sistema operativo VM di 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 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. Prendi in considerazione 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.
Per prevenire o risolvere questo problema, puoi procedere nel seguente modo:
- Se possibile, utilizza immagini batch o immagini personalizzate basate su immagini batch, che non sono interessate da questo problema.
- Se non riesci a utilizzare un'immagine Batch, prova l'ultima versione dell'immagine Compute Engine che preferisci. In generale, le versioni più recenti delle immagini Compute Engine hanno più probabilità di avere la versione del kernel più recente rispetto alle versioni precedenti.
- Se l'ultima versione di un'immagine specifica non funziona, potresti dover provare un altro sistema operativo o creare un'immagine personalizzata. Ad esempio, se l'ultima versione 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 l'ultima versione del kernel.
Questo problema è causato da una versione del kernel obsoleta nell'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 lavori diversi e cambiare nel tempo e potrebbero richiedere che l'immagine del sistema operativo della VM abbia la versione del kernel più recente. Questo problema si verifica quando l'aggiornamento della versione del kernel richiede il riavvio della VM, il che causa l'installazione del pacchetto e l'errore del 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 a I job potrebbero non riuscire quando vengono specificate immagini del sistema operativo VM Compute Engine (o personalizzate) con kernel obsoleti. Nello specifico, 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, puoi anche risolvere gli errori semplicemente installando manualmente i driver GPU.
Per ulteriori informazioni sulle GPU, consulta Crea ed esegui un job che utilizza le GPU.