Diese Seite wurde von der Cloud Translation API übersetzt.

Bekannte Probleme

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.

In Zeitüberschreitungsprotokollen wird nicht angegeben, ob das Zeitlimit der Aufgabe oder des ausführbaren Programms überschritten wurde

Wenn ein Job aufgrund einer Zeitüberschreitung fehlschlägt, wird in den zugehörigen Protokollen nicht angegeben, ob der Fehler durch die Zeitüberschreitung der entsprechenden Aufgabe oder der entsprechenden ausführbaren Datei verursacht wurde.

Legen Sie zum Umgehen dieses Problems unterschiedliche Zeitüberschreitungswerte für Aufgaben und ausführbare Dateien fest. Anschließend können Sie mithilfe der folgenden Schritte feststellen, ob ein Fehler durch das Überschreiten des Zeitlimits der entsprechenden Aufgabe oder ausführbaren Datei verursacht wurde:

Identifizieren Sie die Aufgabe, das ausführbare Programm und die Zeit eines Fehlers, bei dem die Zeitüberschreitung überschritten wurde.
1. Logs für den Job ansehen
2. Suchen Sie nach einem Log, in dem der Exit-Code für die Zeitüberschreitung, 50005, erwähnt wird. Dieses Protokoll enthält eine textPayload, die der folgenden Meldung ähnelt:
```
Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
```
  In diesem Protokoll erfassen Sie TASK_INDEX als fehlgeschlagene Aufgabe, RUNNABLE_INDEX als fehlgeschlagenes ausführbares Element und den timestamp-Wert des Protokolls als Zeitpunkt des Fehlers, bei dem die Zeitüberschreitung überschritten wurde.
Geben Sie die Startzeit der fehlgeschlagenen Aufgabe an.
1. Statusereignisse der fehlgeschlagenen Aufgabe ansehen
2. Suchen Sie nach dem Statusereignis, in dem die folgende Meldung erwähnt wird:
```
Task state is updated from ASSIGNED to RUNNING
```
  Erfassen Sie in diesem Statusereignis das Feld eventTime als Startzeit der fehlgeschlagenen Aufgabe.
Berechnen Sie die Gesamtausführungszeit der fehlgeschlagenen Aufgabe, \({failedTaskRunTime}\), mit der folgenden Formel:

\[{failedTaskRunTime}={failureTime}-{failedTaskStartTime}\]

Ersetzen Sie die folgenden Werte:
- \({failureTime}\): die Uhrzeit des Fehlers, der durch eine Zeitüberschreitung verursacht wurde.
- \({failedTaskStartTime}\): die Startzeit der fehlgeschlagenen Aufgabe.
Überprüfen Sie, welches Zeitlimit überschritten wurde:
- Wenn \({failedTaskRunTime}\) mit der Zeitüberschreitung übereinstimmt, die Sie für die fehlgeschlagene Aufgabe konfiguriert haben, wurde die Zeitüberschreitung dieser fehlgeschlagenen Aufgabe überschritten und hat den Fehler verursacht.
- Andernfalls wurde die Zeitüberschreitung, die Sie für das fehlgeschlagene ausführbare Element konfiguriert haben, überschritten und hat den Fehler verursacht.

Jobs, die Reservierungen verbrauchen, werden möglicherweise verzögert oder verhindert.

Wenn Sie versuchen, einen Job zu erstellen und auszuführen, der Compute Engine-Reservierungen beansprucht, verzögert oder verhindert Batch möglicherweise fälschlicherweise die Ausführung des Jobs. Insbesondere müssen Projekte für Batch-Jobs ausreichende Compute Engine-Ressourcenkontingente haben, auch wenn diese Ressourcenkontingente von nicht in Anspruch genommenen Reservierungen verwendet werden.

Problemumgehung

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. Wenn Sie dieses Label verwenden, 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 Script-Job verhindern oder beheben möchten, der Reservierungen verbrauchen kann, 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.

Problem identifizieren

Dieses Problem wird nicht durch eine bestimmte Fehlermeldung angezeigt. Stattdessen kann dieses Problem in den folgenden Fällen auftreten:

Wenn für Ihr Projekt alle Ressourcen reserviert sind, für die es ein Kontingent gibt, verhindert dieses Problem alle Jobs, für die diese Ressourcen angegeben sind.

Angenommen, Ihr Projekt hat Folgendes:
- Ein maximales Kontingent von 16 H100-GPUs.
- Eine nicht verbrauchte Reservierung für ein einzelnes Projekt für 2 a3-highgpu-8g-VMs, die insgesamt 16 H100-GPUs reserviert.
In diesem Fall kann in Ihrem Projekt kein Job geplant und ausgeführt werden, der korrekt für die Nutzung einer der reservierten H100-GPUs konfiguriert ist.
Wenn für Ihr Projekt einige der Ressourcen reserviert sind, für die es ein Kontingent hat, kann dies dazu führen, dass Jobs, für die diese Ressourcen angegeben sind, verhindert oder verzögert werden.

Angenommen, Ihr Projekt hat Folgendes:
- Ein maximales Kontingent von 16 H100-GPUs.
- Eine nicht verbrauchte Reservierung für ein einzelnes Projekt für 1 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 dann neu erstellt wird. (Diese VM verwendet 8 nicht reservierte H100-GPUs, sofern vorhanden.)
In diesem Szenario können in Ihrem Projekt nur Jobs geplant und ausgeführt werden, die so konfiguriert sind, dass sie eine der reservierten H100-GPUs nutzen, wenn die a3-highgpu-8g-VM nicht vorhanden ist.

Jobs können fehlschlagen, wenn Sie Compute Engine- oder benutzerdefinierte VM-Betriebssystem-Images mit veralteten Kerneln angeben.

Ein Job schlägt möglicherweise fehl, wenn für ihn ein Compute Engine-VM-Betriebssystem-Image angegeben wird, das nicht die neueste Kernelversion hat. Dieses Problem betrifft auch benutzerdefinierte 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. Berücksichtigen Sie dieses Problem stattdessen, wenn ein Job unerwartet fehlschlägt und ein Compute Engine-VM-Betriebssystem-Image oder ein ähnliches benutzerdefiniertes Image angegeben ist.

So können Sie dieses Problem vermeiden oder beheben:

Verwenden Sie nach Möglichkeit Batch-Images oder benutzerdefinierte Images, die auf Batch-Images basieren und von diesem Problem nicht betroffen sind.
Wenn Sie kein Batch-Image verwenden können, versuchen Sie es mit der neuesten Version Ihres bevorzugten Compute Engine-Images. Im Allgemeinen ist es bei neueren Versionen von Compute Engine-Images wahrscheinlicher, dass sie 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 VM-Betriebssystem-Image verursacht, die zum Neustart der VM führt. Wenn für einen Job ein VM-Betriebssystem-Image angegeben wird, das nicht von Batch stammt oder auf einem Batch-Image basiert, installiert Batch die erforderlichen Pakete nach dem Start auf den VMs des Jobs. Die erforderlichen Pakete können für verschiedene Jobs variieren und sich im Laufe der Zeit ändern. Möglicherweise muss das Betriebssystem-Image Ihrer VM die neueste Kernelversion haben. Dieses Problem tritt auf, wenn für die Aktualisierung der Kernelversion ein Neustart der VM erforderlich ist, was zum Abbruch der Paketinstallation und des Jobs führt.

Weitere Informationen zu VM-Betriebssystem-Images finden Sie unter Übersicht über die Betriebssystemumgebung für die VMs eines Jobs.

Jobs, die GPUs und VM-Betriebssystem-Images mit veralteten Kerneln verwenden, schlagen möglicherweise nur bei der automatischen Installation von Treibern fehl.

Dieses Problem hängt eng mit dem Problem zusammen, dass Jobs möglicherweise fehlschlagen, wenn Compute Engine- oder benutzerdefinierte VM-Betriebssystem-Images mit veralteten Kerneln angegeben werden. Insbesondere Jobs, für die ein Compute Engine- oder benutzerdefiniertes VM-Betriebssystem-Image ohne den neuesten Kernel angegeben ist und die GPUs verwenden, können nur dann fehlschlagen, wenn Sie versuchen, GPU-Treiber automatisch zu installieren. Bei diesen Jobs können Sie die Fehler auch beheben, indem Sie die GPU-Treiber manuell installieren.

Weitere Informationen zu GPUs finden Sie unter Job mit GPUs erstellen und ausführen.