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 entsprechenden Aufgabe oder des entsprechenden ausführbaren Elements 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 ermitteln.
Suchen Sie nach einem Log, in dem der Exit-Code für Zeitüberschreitung,
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_INDEXals fehlgeschlagene Aufgabe,RUNNABLE_INDEXals 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
eventTimeals 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 verwendet werden, 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, dass er ausgeführt wird. 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.
Weitere Informationen zu diesem Problem:
- Weitere Informationen dazu, wie und wann sich dieses Problem auf Jobs auswirkt, finden Sie unter Dieses Problem erkennen und verstehen.
- Informationen dazu, wie Sie dieses Problem vermeiden oder beheben können, finden Sie unter Dieses Problem umgehen.
Problem identifizieren und verstehen
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 einer der reservierten H100-GPUs richtig 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, mit der insgesamt 8 H100-GPUs reserviert werden. - Eine
a3-highgpu-8g-VM, die so konfiguriert ist, dass sie keine Reservierungen nutzt und gelegentlich gelöscht und neu erstellt wird. Diese VM verwendet 8 nicht reservierte H100-GPUs, sofern sie vorhanden ist.
In diesem Szenario kann Ihr Projekt nur Jobs planen und ausführen, die richtig konfiguriert sind, um eine der reservierten H100-GPUs zu verwenden, wenn die
a3-highgpu-8g-VM nicht vorhanden ist.
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 der Job nutzen soll.
Weitere Informationen finden Sie unter Job erstellen und ausführen, der reservierte VMs nutzen kann und Benutzerdefinierte Labels für den Job definieren.
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 Compute Engine-VM-Betriebssystem-Image angibt, das nicht die neueste Kernel-Version hat. Dieses Problem betrifft auch alle benutzerdefinierten Images, die auf Compute Engine-VM-Betriebssystem-Images basieren. Dieses Problem kann auftreten, wenn ein Job unerwartet fehlschlägt und ein Betriebssystem-Image für eine Compute Engine-VM oder ein ähnliches benutzerdefiniertes Image angegeben wird. Dieses Problem kann jederzeit bei allen Compute Engine-Images auftreten, auch bei der neuesten Version. Wir haben jedoch festgestellt, dass es hauptsächlich bei Debian Compute Engine-Images auftritt.
Weitere Informationen zu diesem Problem:
- Weitere Informationen dazu, wie und wann sich dieses Problem auf Jobs auswirkt, finden Sie unter Dieses Problem erkennen und verstehen.
- Informationen dazu, wie Sie dieses Problem vermeiden oder beheben können, finden Sie unter Dieses Problem umgehen.
Problem identifizieren und verstehen
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-Betriebssystemimage 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 für das Betriebssystem-Image Ihrer VM die neueste Kernel-Version erforderlich. Dieses Problem tritt auf, wenn für die Aktualisierung der Kernel-Version ein Neustart der VM erforderlich ist. Dadurch schlägt die Paketinstallation und der Job fehl.
Dieses Problem kann jederzeit auftreten, auch wenn Sie die neueste Version eines Compute Engine-Images verwenden. Wenn ein Betriebssystem vor Kurzem aktualisiert wurde, insbesondere bei unvorhersehbaren Updates wie Hotfixes – dringende Updates für Sicherheitslücken oder kritische Probleme –, konnten die Betriebssystem-Images für Compute Engine-VMs möglicherweise noch nicht auf die Änderungen reagieren. Bei Debian OS können beispielsweise Pakete mit linux-headers--Präfixen durch Hotfixes unvorhersehbar aus dem Kernel entfernt werden.
Um dieses Problem zu identifizieren, empfehlen wir Ihnen, die Logs für den Job anzusehen, um nach Installationsfehlern im Zusammenhang mit dem VM-Betriebssystem-Image zu suchen. Wenn für Ihren Job beispielsweise ein Debian Compute Engine-Image oder ein ähnliches benutzerdefiniertes Image verwendet wird, empfehlen wir, mit der folgenden Abfrage nach Fehlern bei der Installation von linux-headers--Paketen zu suchen:
labels.job_uid="JOB_UID" AND severity="ERROR" AND textPayload:("failed" "apt" "install" "linux-headers-")
Ersetzen Sie JOB_UID durch die eindeutige ID (UID) des Jobs.
Wenn Sie die UID eines Jobs abrufen möchten, beschreiben Sie den Job.
Wenn diese Abfrage Ergebnisse zurückgibt, ist Ihr Job möglicherweise von diesem Problem betroffen.
Problem umgehen
Wir empfehlen Ihnen, Folgendes zu tun, um dieses Problem zu vermeiden oder zu beheben:
Verwenden Sie nach Möglichkeit Batch-Bilder oder benutzerdefinierte Bilder, die auf Batch-Bildern basieren und nicht von diesem Problem betroffen sind.
Probieren Sie die aktuelle Version Ihres bevorzugten Compute Engine-Images aus. Im Allgemeinen ist es wahrscheinlicher, dass neuere Versionen von Compute Engine-Images die neueste Kernelversion haben als frühere Versionen.
Wählen Sie eine der folgenden Optionen aus:
Versuchen Sie es mit einem anderen Betriebssystem oder erstellen Sie ein benutzerdefiniertes Image. Wenn beispielsweise die neueste Version von Debian 12 nicht funktioniert, können Sie versuchen, ein benutzerdefiniertes Image aus einer Compute Engine-VM zu erstellen, auf der Debian 12 ausgeführt wird und die Sie aktualisiert haben, um die neueste Kernel-Version zu verwenden.
Wenn Ihr Job aufgrund von Fehlern bei der Installation von
linux-headers--Paketen fehlschlägt, können Sie versuchen, das VM-Betriebssystem-Image mit veraltetenlinux-headers--Paketen zu verwenden. Wenn Sie veraltetelinux-headers--Pakete zulassen möchten, fügen Sie dem Feldlabelsauf Jobebene ein Label mit dem Namengoog-batch-allow-insecure-linux-headers-installationund dem Werttruehinzu.Wenn Sie beispielsweise veraltete
linux-headers--Pakete für einen einfachen Skriptjob zulassen möchten, in dem ein VM-Betriebssystem-Image angegeben ist, 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": [ { "policy": { "bootDisk": { "image": "VM_OS_IMAGE_URI" } } } ] }, "labels": { "goog-batch-allow-insecure-linux-headers-installation": "true" }, "logsPolicy": { "destination": "CLOUD_LOGGING" } }Ersetzen Sie
VM_OS_IMAGE_URIdurch den URI des VM-Betriebssystem-Images, das Sie verwenden möchten.Weitere Informationen finden Sie unter Benutzerdefinierte Labels für den Job definieren und Betriebssystem-Image für VMs für einen Job angeben.
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 dem vorherigen Problem Jobs schlagen möglicherweise fehl, wenn Compute Engine-VM-Betriebssystem-Images (oder benutzerdefinierte VM-Betriebssystem-Images) mit veralteten Kernels angegeben werden 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 diesem Problem und zur Behebung finden Sie unter Jobs might fail when specifying Compute Engine (or custom) VM OS images with outdated kernels. Weitere Informationen zu GPUs finden Sie unter Job erstellen und ausführen, der GPUs verwendet.