Bekannte Probleme

Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von Batch.

Weitere Informationen zur Verwendung von Batch finden Sie in der Dokumentation zur Fehlerbehebung oder Support kontaktieren

Logs zu Zeitüberschreitungen geben nicht an, ob das Zeitlimit der Aufgabe oder des ausführbaren Objekts überschritten wurde

Wenn ein Job aufgrund einer Überschreitung eines timeout fehlschlägt, Die mit dem Job verknüpften Logs geben nicht an, ob der Fehler wurde durch das Zeitlimit der relevanten Aufgabe oder des relevanten Runnables verursacht.

Um dieses Problem zu umgehen, legen Sie unterschiedliche Zeitüberschreitungswerte für Aufgaben und Runnables. So können Sie feststellen, ob ein Fehler das Zeitlimit für die relevante Aufgabe überschritten oder ausführbar ist, indem Sie Folgendes verwenden: Vorgehensweise:

1. 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 Log enthält eine textPayload, die der folgenden Nachricht ähnelt:

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

      Aus diesem Log notieren Sie TASK_INDEX als fehlgeschlagene Aufgabe, RUNNABLE_INDEX als fehlgeschlagene ausführbare Datei und der Wert timestamp des Logs als Zeitangabe wenn das Zeitlimit überschritten wurde.

2. Ermitteln Sie die Startzeit der fehlgeschlagenen Aufgabe.

   1. Statusereignisse der fehlgeschlagenen Aufgabe ansehen

   2. Suchen Sie das Statusereignis, das die folgende Nachricht enthält:

      Task state is updated from ASSIGNED to RUNNING
      

      Erfassen Sie in diesem Statusereignis das Feld eventTime als Startzeit der fehlgeschlagenen Aufgabe.

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

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

   Ersetzen Sie die folgenden Werte:

   • \({failureTime}\): Der Zeitpunkt des Fehlers beim Überschreiten des Zeitlimits.
   • \({failedTaskStartTime}\): die Startzeit der fehlgeschlagenen Aufgabe.

4. Ermitteln Sie das überschrittene Zeitlimit:

   • 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 Kontingente 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.

Wichtig :Das Aktivieren der Funktion Label goog-batch-skip-quota-check für Jobs, die keine Reservierungen nutzen können in Ihrem Projekt. Vermeiden Sie diese Behelfslösung, wenn Ihr Projekt keine Compute Engine-Reservierungen haben oder für einen Job VMs erforderlich sind die mit diesen Reservierungen nicht kompatibel sind. Andernfalls werden Jobs Kontingentprüfungen unnötigerweise überspringen, sehen Sie möglicherweise unnötige unzureichende Kontingentfehler.

Um dieses Problem zu verhindern oder zu beheben, einfachen Skriptjob, der Reservierungen nutzen kann, und einen Job mit dem folgende JSON-Konfiguration:

{
  "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 Anweisungen finden Sie unter Job erstellen und ausführen, der reservierte VMs nutzen kann und Definieren Sie benutzerdefinierte Labels für den Job.

Problem identifizieren

Dieses Problem wird nicht durch eine spezifische Fehlermeldung gekennzeichnet. 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 genutzte Reservierung eines Projekts für 1 a3-highgpu-8g-VM, die reserviert insgesamt 8 H100-GPUs.
  • Eine a3-highgpu-8g-VM, die so konfiguriert ist, dass sie keine Reservierungen in Anspruch nimmt, und gelegentlich gelöscht und dann neu erstellt wird. (Diese VM verwendet 8 nicht reservierte H100-GPUs, sofern vorhanden.)

  In diesem Szenario ermöglicht dieses Problem nur, mit der Ausführung aller richtigen Jobs starten, eine der reservierten H100-GPUs verbrauchen, wenn die VM a3-highgpu-8g existieren.

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 Betriebssystem-Image einer Compute Engine-VM angibt die nicht die neueste Kernel-Version 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. Überlegen Sie sich stattdessen, Dieses Problem tritt auf, wenn ein Job unerwartet fehlschlägt und ein Compute Engine-VM-Betriebssystem-Image oder ein ähnliches benutzerdefiniertes Image.

So können Sie dieses Problem verhindern oder beheben:

Hinweis: Wenn für Ihren Job GPUs verwendet werden, lesen Sie auch den Hilfeartikel Jobs mit GPUs und VM-Betriebssystem-Images mit veralteten Kerneln schlagen nur bei automatischer Treiberinstallation fehl.

1. Verwenden Sie nach Möglichkeit Batch-Images oder benutzerdefinierte Images auf Batch-Images basieren, die hiervon Problem.
2. Wenn Sie ein Batch-Image nicht verwenden können, versuchen Sie es mit der aktuellen Version Version Ihres bevorzugten Compute Engine-Images. Im Allgemeinen neuerer Versionen von Compute Engine-Images die neueste Kernel-Version als ältere Versionen haben.
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 11 nicht funktioniert, können versuchen, Erstellen eines benutzerdefinierten Images anhand eines Compute Engine-VM, auf der Debian 11 ausgeführt wird und die Sie aktualisiert haben um die neueste Kernel-Version zu verwenden.

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 mit Jobs schlagen möglicherweise fehl, wenn Compute Engine- oder benutzerdefinierte VM-Betriebssystem-Images mit veralteten Kerneln angegeben werden. Insbesondere Jobs, die beide ein Compute Engine- oder benutzerdefiniertes VM-Betriebssystem-Image ohne den neuesten Kernel und GPUs verwenden, schlagen möglicherweise nur dann fehl, wenn Sie versuchen, GPU-Treiber zu installieren. automatisch. 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.