Bekannte Probleme

Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von Batch auftreten können.

Wenn Sie weitere Hilfe bei der Verwendung von Batch benötigen, lesen Sie die Dokumentation zur Fehlerbehebung oder Support anfordern.

Zeitüberschreitungslogs geben nicht an, ob das Zeitlimit der Task oder des ausführbaren Elements überschritten wurde

Wenn ein Job aufgrund einer Zeitüberschreitung fehlschlägt, geben die mit dem Job verknüpften Logs nicht an, ob der Fehler durch das Zeitlimit der entsprechenden Aufgabe oder das Zeitlimit der entsprechenden ausführbaren Datei verursacht wurde.

Sie können dieses Problem umgehen, indem Sie unterschiedliche Zeitüberschreitungswerte für Tasks und Runnables festlegen. Dann können Sie mit dem folgenden Verfahren ermitteln, ob ein Fehler durch das Überschreiten des Zeitlimits der entsprechenden Aufgabe oder des ausführbaren Elements verursacht wurde:

1. Ermitteln Sie die Task, das ausführbare und das Zeitpunkt eines überschrittenen Zeitüberschreitungsfehlers.

   1. Logs für den Job ansehen

   2. Suchen Sie ein Protokoll, das den Exit-Code 50005 für eine überschrittene Zeitüberschreitung enthält. Dieses Log enthält ein textPayload, das der folgenden Nachricht ähnelt:

      Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
      

      Notieren Sie in diesem Log TASK_INDEX als fehlgeschlagene Aufgabe, RUNNABLE_INDEX als fehlgeschlagene Runnable und als timestamp-Wert des Logs den Zeitpunkt des überschrittenen Zeitüberschreitungsfehlers.

2. Ermitteln Sie die Startzeit der fehlgeschlagenen Aufgabe.

   1. Statusereignisse der fehlgeschlagenen Aufgabe ansehen

   2. Suchen Sie nach dem Statusereignis mit der folgenden Nachricht:

      Task state is updated from ASSIGNED to RUNNING
      

      Notieren Sie bei diesem Statusereignis das Feld eventTime als Startzeit der fehlgeschlagenen Aufgabe.

3. Berechnen Sie die Gesamtausführungszeit der fehlgeschlagenen Aufgabe, \({failedTaskRunTime}\), mithilfe der folgenden Formel:

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

   Ersetzen Sie die folgenden Werte:

   • \({failureTime}\): die Zeit des überschrittenen Zeitüberschreitungsfehlers.
   • \({failedTaskStartTime}\): die Startzeit der fehlgeschlagenen Aufgabe.

4. Ermitteln Sie das überschrittene Zeitlimit:

   • Wenn \({failedTaskRunTime}\) mit dem Zeitlimit übereinstimmt, das Sie für die fehlgeschlagene Aufgabe konfiguriert haben, wurde das Zeitlimit dieser fehlgeschlagenen Aufgabe überschritten und den Fehler verursacht.

   • Andernfalls wurde das Zeitlimit, das Sie für das fehlgeschlagene Runnable konfiguriert haben, überschritten und hat den Fehler verursacht.

Jobs, die Reservierungen nutzen, können sich verzögern oder ganz verhindern

Wenn Sie versuchen, einen Job zu erstellen und auszuführen, der Compute Engine-Reservierungen nutzt, kann Batch den Job fälschlicherweise verzögern oder die Ausführung des Jobs verhindern. Insbesondere für Batch müssen Projekte genügend Compute Engine-Ressourcenkontingente haben, auch wenn diese Ressourcenkontingente von nicht verbrauchten Reservierungen verwendet werden.

Umgehung des Problems

Zum Umgehen dieses Problems für einen Job fügen Sie dem Feld labels auf Jobebene ein Label mit dem Namen goog-batch-skip-quota-check und dem Wert true hinzu. Dieses Label führt dazu, dass Batch die Prüfung der Ressourcenkontingente Ihres Projekts überspringt, bevor versucht wird, einen Job zu erstellen.

Wichtig: Es wird nicht empfohlen, das Label goog-batch-skip-quota-check für Jobs zu aktivieren, die keine Reservierungen in Ihrem Projekt nutzen können. Sie können diese Problemumgehung beispielsweise vermeiden, wenn Ihr Projekt keine Compute Engine-Reservierungen hat oder ein Job VMs erfordert, die mit diesen Reservierungen nicht kompatibel sind. Wenn Jobs Kontingentprüfungen unnötigerweise überspringen, kann es zu unzureichenden Kontingentfehlern kommen.

Um dieses Problem beispielsweise bei einem einfachen Skriptjob zu verhindern oder zu beheben, der Reservierungen nutzen kann, erstellen Sie einen Job mit der folgenden JSON-Konfiguration und führen Sie ihn 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 ermitteln

Dieses Problem wird durch keine spezifische Fehlermeldung angegeben. Stattdessen kann dieses Problem unter folgenden Umständen auftreten:

• Wenn Ihr Projekt alle Ressourcen reserviert, für die es Kontingente hat, werden dadurch Jobs verhindert, die diese Ressourcen angeben.

  Angenommen, Ihr Projekt umfasst Folgendes:

  • Ein maximales Kontingent von 16 für H100-GPUs.
  • Eine nicht genutzte Reservierung für ein einzelnes Projekt für 2 a3-highgpu-8g-VMs, die insgesamt 16 H100-GPUs reserviert.

  In diesem Szenario hindert das Projekt daran, Jobs zu planen und auszuführen, die korrekt konfiguriert sind, um eine der reservierten H100-GPUs zu nutzen.

• Wenn Ihr Projekt einige der Ressourcen reserviert, für die es Kontingente hat, kann dieses Problem Jobs verhindern oder verzögern, die diese Ressourcen angeben.

  Angenommen, Ihr Projekt umfasst Folgendes:

  • Ein maximales Kontingent von 16 für H100-GPUs.
  • Eine nicht verbrauchte Reservierung für ein einzelnes Projekt für 1 a3-highgpu-8g-VM, die insgesamt 8 H100-GPUs reserviert.
  • Eine a3-highgpu-8g-VM, die so konfiguriert ist, dass sie keine Reservierungen nutzt, gelegentlich gelöscht und dann neu erstellt wird. (Diese VM verwendet 8 nicht reservierte H100-GPUs, sofern vorhanden.)

  In diesem Szenario verhindert dieses Problem, dass Ihr Projekt jeden Job, der so konfiguriert ist, dass er eine der reservierten H100-GPUs nutzt, geplant und ausführt, wenn die VM a3-highgpu-8g nicht vorhanden ist.

Jobs schlagen möglicherweise fehl, wenn Compute Engine- (oder benutzerdefinierte) VM-Betriebssystem-Images mit veralteten Kerneln 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. Die öffentlichen Compute Engine-Images, die dieses Problem verursachen, sind nicht leicht zu erkennen und können jederzeit geändert werden.

Dieses Problem wird nicht durch eine spezifische Fehlermeldung angegeben. Stellen Sie sich stattdessen dieses Problem, wenn Sie einen Job haben, der unerwartet fehlschlägt und ein Compute Engine-VM-Betriebssystem-Image oder ein ähnliches benutzerdefiniertes Image angibt.

Gehen Sie folgendermaßen vor, um dieses Problem zu verhindern oder zu beheben:

Hinweis: Wenn Ihr Job GPUs verwendet, lesen Sie auch den Abschnitt Jobs, die GPUs und VM-Betriebssystem-Images mit veralteten Kerneln verwenden, schlagen nur bei der automatischen Installation von Treibern fehl.

1. Verwenden Sie nach Möglichkeit Batch-Images oder benutzerdefinierte Images, die auf Batch-Images basieren. Diese sind von diesem Problem nicht betroffen.
2. Wenn Sie kein Batch-Image verwenden können, versuchen Sie es mit der neuesten Version Ihres bevorzugten Compute Engine-Images. Im Allgemeinen verwenden neuere Versionen von Compute Engine-Images eher die neueste Kernel-Version als ältere.
3. Wenn die neueste Version eines bestimmten Images nicht funktioniert, müssen Sie es möglicherweise mit einem anderen Betriebssystem versuchen oder ein benutzerdefiniertes Image erstellen. Wenn beispielsweise die neueste Version von Debian 11 nicht funktioniert, können Sie versuchen, ein benutzerdefiniertes Image von einer Compute Engine-VM zu erstellen, auf der Debian 11 ausgeführt wird und die Sie auf die neueste Kernel-Version aktualisiert haben.

Dieses Problem wird durch eine veraltete Kernel-Version im VM-Betriebssystem-Image verursacht, die dazu führt, dass die VM neu gestartet wird. Wenn ein Job ein VM-Betriebssystem-Image angibt, das nicht aus Batch oder auf einem Batch-Image basiert, installiert Batch die erforderlichen Pakete nach dem Start auf den VMs des Jobs. Die erforderlichen Pakete können je nach Job variieren und sich im Laufe der Zeit ändern. Außerdem muss Ihr VM-Betriebssystem-Image möglicherweise die neueste Kernel-Version haben. Dieses Problem tritt auf, wenn beim Aktualisieren der Kernel-Version die VM neu gestartet werden muss, wodurch die Paketinstallation und der Job fehlschlagen.

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 fehl, wenn Treiber automatisch installiert werden

Dieses Problem ist eng mit der folgenden Ursache verbunden: Jobs können fehlschlagen, wenn Sie Compute Engine- oder benutzerdefinierte VM-Betriebssystem-Images mit veralteten Kerneln angeben. Insbesondere schlagen Jobs, die ein Compute Engine- (oder benutzerdefiniertes) VM-Betriebssystem-Image ohne den neuesten Kernel angeben und GPUs verwenden, möglicherweise nur fehl, wenn Sie versuchen, GPU-Treiber automatisch zu installieren. Bei diesen Jobs können Sie die Fehler auch beheben, indem Sie einfach die GPU-Treiber manuell installieren.

Weitere Informationen zu GPUs finden Sie unter Job erstellen und ausführen, der GPUs verwendet.