Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von Batch auftreten können.
Weitere Informationen zur Verwendung von Batch finden Sie in der Dokumentation zur Fehlerbehebung oder unter Support erhalten.
Bei schnellen Änderungen werden möglicherweise keine Pub/Sub-Benachrichtigungen für Zwischenstatus gesendet.
Pub/Sub sendet möglicherweise nicht für alle Zwischenstatus Benachrichtigungen, wenn sich ein Job oder eine Aufgabe sehr schnell ändert. Angenommen, der Status einer Aufgabe ändert sich schnell von ASSIGNED
zu RUNNING
und dann zu FAILED
. In diesem Fall erhalten Sie möglicherweise keine Benachrichtigung, dass die Aufgabe den Status RUNNING
erreicht hat.
Um dieses Problem zu beheben, empfehlen wir, dass Sie sich Statusereignisse ansehen, anstatt Pub/Sub-Benachrichtigungen zu verwenden, wenn Sie den vollständigen Statusverlauf eines Jobs oder einer Aufgabe sehen möchten.
Weitere Informationen zu Pub/Sub-Benachrichtigungen finden Sie unter Jobstatus mit Pub/Sub-Benachrichtigungen und BigQuery überwachen.
Timeout-Logs geben nicht an, ob das Zeitlimit für die Aufgabe oder den Runnable überschritten wurde.
Wenn ein Job aufgrund einer Zeitüberschreitung fehlschlägt, geben die zugehörigen Logs nicht an, ob der Fehler durch die Zeitüberschreitung der relevanten Aufgabe oder des relevanten Runnable verursacht wurde.
Um dieses Problem zu umgehen, legen Sie unterschiedliche Zeitüberschreitungswerte für Aufgaben und Runnable-Objekte fest. Anschließend können Sie mit der folgenden Vorgehensweise ermitteln, ob ein Fehler durch Überschreiten des Zeitlimits der entsprechenden Aufgabe oder des entsprechenden Runnable verursacht wurde:
Aufgabe, ausführbare Datei und Zeitpunkt eines Fehlers aufgrund eines überschrittenen Zeitlimits identifizieren.
Suchen Sie nach einem Log, in dem der Exit-Code für Zeitüberschreitung (exceeded-timeout)
50005
erwähnt wird. Dieses Log enthält einetextPayload
, die der folgenden Meldung ähnelt:Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
Notieren Sie aus diesem Log
TASK_INDEX
als fehlgeschlagene Aufgabe,RUNNABLE_INDEX
als fehlgeschlagenen Runnable und dentimestamp
-Wert des Logs als Zeitpunkt des Fehlers aufgrund des überschrittenen Zeitlimits.
Ermitteln Sie die Startzeit der fehlgeschlagenen Aufgabe.
Suchen Sie nach dem Statusereignis, in dem die folgende Meldung erwähnt wird:
Task state is updated from ASSIGNED to RUNNING
Erfassen Sie aus diesem Statusereignis das Feld
eventTime
als Startzeit der fehlgeschlagenen Aufgabe.
Berechnen Sie die Gesamtlaufzeit der fehlgeschlagenen Aufgabe, \({failedTaskRunTime}\), mit der folgenden Formel:
\[{failedTaskRunTime}={failureTime}-{failedTaskStartTime}\]
Ersetzen Sie die folgenden Werte:
- \({failureTime}\): Die Uhrzeit des Fehlers aufgrund von Zeitüberschreitung.
- \({failedTaskStartTime}\): Die Startzeit der fehlgeschlagenen Aufgabe.
Ermitteln Sie das überschrittene Zeitlimit:
Wenn \({failedTaskRunTime}\) mit dem Zeitlimit übereinstimmt, das Sie für die fehlgeschlagene Aufgabe konfiguriert haben, wurde das Zeitlimit der fehlgeschlagenen Aufgabe überschritten und hat den Fehler verursacht.
Andernfalls wurde das von Ihnen konfigurierte Zeitlimit für den fehlgeschlagenen Runnable überschritten und hat den Fehler verursacht.
Jobs, für die Reservierungen erforderlich sind, können sich verzögern oder nicht ausgeführt werden
Wenn Sie versuchen, einen Job zu erstellen und auszuführen, der Compute Engine-Reservierungen nutzt, kann es sein, dass Batch den Job fälschlicherweise verzögert oder verhindert. Insbesondere erfordert Batch, dass Projekte über ein ausreichendes Kontingent für Compute Engine-Ressourcen verfügen, auch wenn diese Ressourcenkontingente von nicht genutzten Reservierungen verwendet werden.
Problem umgehen
Um dieses Problem für einen Job zu umgehen, fügen Sie dem Feld labels
auf Jobebene ein Label mit dem Namen goog-batch-skip-quota-check
und dem Wert true
hinzu.
Durch dieses Label wird die Überprüfung der Ressourcenkontingente Ihres Projekts übersprungen, bevor versucht wird, einen Job zu erstellen.
Wenn Sie dieses Problem beispielsweise für einen einfachen Skriptjob, der Reservierungen nutzen kann, verhindern oder beheben möchten, erstellen und führen Sie einen Job mit der folgenden JSON-Konfiguration aus:
{
"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"
}
}
Ersetzen Sie VM_RESOURCES
durch die VM-Ressourcen, die der Reservierung entsprechen, die für den Job verwendet werden soll.
Weitere Informationen finden Sie unter Job erstellen und ausführen, der reservierte VMs nutzen kann und Benutzerdefinierte Labels für den Job definieren.
Problem ermitteln
Dieses Problem wird nicht durch eine bestimmte Fehlermeldung angezeigt. Stattdessen kann dieses Problem unter den folgenden Umständen auftreten:
Wenn in Ihrem Projekt alle Ressourcen reserviert sind, für die ein Kontingent vorhanden ist, können keine Jobs ausgeführt werden, in denen diese Ressourcen angegeben sind.
Angenommen, Ihr Projekt hat Folgendes:
- Ein maximales Kontingent für H100-GPUs von 16.
- Eine nicht verbrauchte Einzelprojektreservierung für 2
a3-highgpu-8g
-VMs, mit der insgesamt 16 H100-GPUs reserviert werden.
In diesem Szenario wird verhindert, dass in Ihrem Projekt Jobs geplant und ausgeführt werden, die für die Nutzung der reservierten H100-GPUs konfiguriert sind.
Wenn in Ihrem Projekt einige der Ressourcen reserviert sind, für die ein Kontingent vorhanden ist, kann dieses Problem dazu führen, dass Jobs, in denen diese Ressourcen angegeben sind, verhindert oder verzögert werden.
Angenommen, Ihr Projekt hat Folgendes:
- Ein maximales Kontingent für H100-GPUs von 16.
- Eine nicht verbrauchte Einzelprojektreservierung für eine
a3-highgpu-8g
-VM, die insgesamt 8 H100-GPUs reserviert. - Eine
a3-highgpu-8g
-VM, die so konfiguriert ist, dass keine Reservierungen genutzt werden, und die gelegentlich gelöscht und neu erstellt wird. Diese VM verwendet 8 nicht reservierte H100-GPUs, sofern sie vorhanden ist.
In diesem Szenario können in Ihrem Projekt nur Jobs geplant und ausgeführt werden, die richtig konfiguriert sind, um eine der reservierten H100-GPUs zu nutzen, wenn die
a3-highgpu-8g
-VM nicht vorhanden ist.
Jobs schlagen möglicherweise fehl, wenn Compute Engine-VM-Betriebssystem-Images (oder benutzerdefinierte VM-Betriebssystem-Images) mit veralteten Kernels angegeben werden.
Ein Job kann fehlschlagen, wenn er ein Betriebssystem-Image für eine Compute Engine-VM angibt, das nicht die neueste Kernelversion hat. Dieses Problem betrifft auch alle benutzerdefinierten Images, die auf Compute Engine-VM-Betriebssystem-Images basieren. Die öffentlichen Compute Engine-Images, die dieses Problem verursachen, sind nicht leicht zu identifizieren und können sich jederzeit ändern.
Dieses Problem wird nicht durch eine bestimmte Fehlermeldung angezeigt. Dieses Problem sollten Sie in Betracht ziehen, wenn ein Job unerwartet fehlschlägt und ein Betriebssystem-Image für eine Compute Engine-VM oder ein ähnliches benutzerdefiniertes Image angegeben ist.
So können Sie dieses Problem verhindern oder beheben:
- Verwenden Sie nach Möglichkeit Batch-Images oder benutzerdefinierte Images, die auf Batch-Images basieren. Diese sind von diesem Problem nicht betroffen.
- Wenn Sie kein Batch-Image verwenden können, versuchen Sie es mit der neuesten Version Ihres bevorzugten Compute Engine-Images. Im Allgemeinen ist es wahrscheinlicher, dass neuere Versionen von Compute Engine-Images die neueste Kernelversion haben als ältere Versionen.
- Wenn die neueste Version eines bestimmten Images nicht funktioniert, müssen Sie möglicherweise ein anderes Betriebssystem ausprobieren oder ein benutzerdefiniertes Image erstellen. Wenn beispielsweise die neueste Version von Debian 11 nicht funktioniert, können Sie versuchen, ein benutzerdefiniertes Image aus einer Compute Engine-VM zu erstellen, auf der Debian 11 ausgeführt wird und die Sie auf die neueste Kernelversion aktualisiert haben.
Dieses Problem wird durch eine veraltete Kernelversion im Betriebssystem-Image der VM verursacht, die dazu führt, dass die VM neu gestartet wird. Wenn in einem Job ein VM-Betriebssystem-Image angegeben ist, das nicht von Batch stammt oder auf einem Batch-Image basiert, installiert Batch die erforderlichen Pakete auf den VMs des Jobs, nachdem sie gestartet wurden. Die erforderlichen Pakete können je nach Job variieren und sich im Laufe der Zeit ändern. Möglicherweise ist auch die neueste Kernelversion für das Betriebssystem-Image Ihrer VM erforderlich. Dieses Problem tritt auf, wenn für die Aktualisierung der Kernelversion ein Neustart der VM erforderlich ist. Dadurch schlägt die Paketinstallation und der Job fehl.
Weitere Informationen zu VM-Betriebssystem-Images finden Sie unter Übersicht über die Betriebssystemumgebung für die VMs eines Jobs.
Jobs mit GPUs und VM-Betriebssystem-Images mit veralteten Kerneln schlagen möglicherweise nur fehl, wenn Treiber automatisch installiert werden.
Dieses Problem hängt eng mit Jobs might fail when specifying Compute Engine (or custom) VM OS images with outdated kernels zusammen. Jobs, in denen sowohl ein Compute Engine-VM-Betriebssystemimage (oder ein benutzerdefiniertes VM-Betriebssystemimage) ohne den neuesten Kernel angegeben als auch GPUs verwendet werden, schlagen möglicherweise nur fehl, wenn Sie versuchen, GPU-Treiber automatisch zu installieren. Bei diesen Jobs können Sie die Fehler möglicherweise auch beheben, indem Sie GPU-Treiber manuell installieren.
Weitere Informationen zu GPUs finden Sie unter Job erstellen und ausführen, der GPUs verwendet.