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 erhalten.

Pub/Sub sendet bei schnellen Änderungen möglicherweise keine Benachrichtigungen für Zwischenstatus

Pub/Sub sendet möglicherweise nicht für alle Zwischenstatus Benachrichtigungen, wenn sich der Status eines Jobs oder einer 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.

Wenn Sie den vollständigen Statusverlauf eines Jobs oder einer Aufgabe sehen möchten, rufen Sie Statusereignisse auf anstelle von Pub/Sub-Benachrichtigungen.

Weitere Informationen zu Pub/Sub-Benachrichtigungen finden Sie unter Jobstatus mit Pub/Sub-Benachrichtigungen und BigQuery überwachen.

In den Zeitüberschreitungslogs wird nicht angegeben, ob das Zeitlimit für die Aufgabe oder die ausführbare Einheit überschritten wurde

Wenn ein Job aufgrund einer Zeitüberschreitung fehlschlägt, wird in den mit dem Job verknüpften Logs nicht angegeben, ob der Fehler durch das Zeitlimit der entsprechenden Aufgabe oder das Zeitlimit der entsprechenden ausführbaren Einheit verursacht wurde.

Um dieses Problem zu umgehen, legen Sie unterschiedliche Zeitlimitwerte für Aufgaben und ausführbare Einheiten fest. Anschließend können Sie mit der folgenden Vorgehensweise ermitteln, ob ein Fehler durch eine Zeitüberschreitung der entsprechenden Aufgabe oder ausführbaren Einheit verursacht wurde:

1. Ermitteln Sie die Aufgabe, die ausführbare Einheit und die Uhrzeit eines Fehlers aufgrund einer Zeitüberschreitung.

   1. Rufen Sie die Logs für den Job auf.

   2. Suchen Sie nach einem Log, in dem der Exitcode für die Zeitüberschreitung 50005 erwähnt wird. Dieses Log enthält eine textPayload, die einer Nachricht wie der folgenden ä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 fehlgeschlagene ausführbare Einheit und den timestamp-Wert des Logs als Uhrzeit des Fehlers aufgrund der Zeitüberschreitung.

2. Ermitteln Sie die Startzeit der fehlgeschlagenen Aufgabe.

   1. Rufen Sie die Statusereignisse der fehlgeschlagenen Aufgabe auf.

   2. Suchen Sie nach dem Statusereignis, in dem die folgende Nachricht erwähnt wird:

      Task state is updated from ASSIGNED to RUNNING
      

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

3. 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 der Zeitüberschreitung.
   • \({failedTaskStartTime}\): die Startzeit der fehlgeschlagenen Aufgabe.

4. Ermitteln Sie die überschrittene Zeitüberschreitung:

   • 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 Zeitlimit überschritten, das Sie für die fehlgeschlagene ausführbare Einheit konfiguriert haben, und der Fehler verursacht.

Jobs, die Reservierungen nutzen, können sich verzögern oder verhindert werden

Wenn Sie versuchen, einen Job zu erstellen und auszuführen, der Compute Engine-Reservierungen nutzt, kann es vorkommen, dass Batch den Job fälschlicherweise verzögert oder verhindert. Insbesondere erfordert Batch, dass Projekte über genügend Compute Engine-Ressourcenkontingente 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 auf Jobebenelabels ein Label mit dem Namen goog-batch-skip-quota-check und dem Wert true hinzu. Dieses Label bewirkt, dass Batch die Ressourcenkontingente Ihres Projekts nicht überprüft, bevor versucht wird, einen Job zu erstellen.

Wichtig: Es wird nicht empfohlen, das goog-batch-skip-quota-check Label für Jobs zu aktivieren, die keine Reservierungen in Ihrem Projekt nutzen können. Vermeiden Sie diese Problemumgehung beispielsweise, wenn Ihr Projekt keine Compute Engine-Reservierungen hat oder wenn für einen Job VMs erforderlich sind, die nicht mit diesen Reservierungen kompatibel sind. Andernfalls kann es zu unnötigen Fehlern aufgrund unzureichender Kontingentekommen, wenn bei Jobs unnötigerweise Kontingentprüfungen übersprungen werden.

Wenn Sie dieses Problem beispielsweise für einen einfachen Skriptjob verhindern oder beheben möchten, der Reservierungen nutzen 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 ermitteln

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

• Wenn in Ihrem Projekt alle Ressourcen reserviert sind, für die ein Kontingent vorhanden ist, verhindert dieses Problem alle Jobs, die diese Ressourcen angeben.

  Angenommen, Ihr Projekt hat Folgendes:

  • Ein maximales Kontingent für H100-GPUs von 16.
  • Eine nicht genutzte Einzelprojektreservierung für zwei a3-highgpu-8g-VMs, die insgesamt 16 H100-GPUs reserviert.

  In diesem Fall verhindert dieses Problem, dass in Ihrem Projekt Jobs geplant und ausgeführt werden, die korrekt konfiguriert sind, um eine der reservierten H100-GPUs zu nutzen.

• Wenn in Ihrem Projekt einige der Ressourcen reserviert sind, für die ein Kontingent vorhanden ist, kann dieses Problem Jobs verhindern oder verzögern, die diese Ressourcen angeben.

  Angenommen, Ihr Projekt hat Folgendes:

  • Ein maximales Kontingent für H100-GPUs von 16.
  • Eine nicht genutzte Einzelprojektreservierung für eine a3-highgpu-8g-VM, die insgesamt 8 H100-GPUs reserviert.
  • 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, wenn sie vorhanden ist.

  In diesem Fall können in Ihrem Projekt nur dann Jobs geplant und ausgeführt werden, die korrekt konfiguriert sind, um eine der reservierten H100-GPUs zu nutzen, wenn die a3-highgpu-8g-VM nicht vorhanden ist.

Jobs können fehlschlagen, wenn Compute Engine-VM-Betriebssystem-Images (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 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 angibt.

So können Sie dieses Problem verhindern oder beheben:

**Hinweis**: Wenn Ihr Job GPUs verwendet, lesen Sie auch Jobs, die GPUs verwenden, und VM-Betriebssystem-Images mit veralteten Kerneln 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 haben neuere Versionen von Compute Engine-Images eher die neueste Kernelversion als ältere Versionen.
3. 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 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 so aktualisiert haben, dass sie die neueste Kernelversion verwendet.

Dieses Problem wird durch eine veraltete Kernelversion 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 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 es erforderlich, dass Ihr VM-Betriebssystem-Image die neueste Kernel-Version hat. Dieses Problem tritt auf, wenn für die Aktualisierung der Kernel-Version ein Neustart der VM erforderlich ist, 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 bei der automatischen Installation von Treibern fehl

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

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