Kontingente und Limits

Batch verwendet Kontingente und Systemlimits, um eine faire Ressourcenzuweisung zu gewährleisten, Dienstüberlastungen zu vermeiden und Ihnen bei der Verwaltung der Ressourcennutzung zu helfen.

Kontingente und Systemlimits sind ähnlich, unterscheiden sich aber in folgenden Punkten:

  • Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
  • Systemlimits sind feste Werte, die nicht geändert werden können.

Batchjobs werden auf Compute Engine-Ressourcen ausgeführt. Daher unterliegt Batch auch den Kontingenten und Limits von Compute Engine. Wenn Ihr Batch-Job auch andere Google Cloud -Dienste verwendet, unterliegt er auch den Kontingenten für diese Dienste. Versuche, ein Kontingent oder Limit zu überschreiten, führen zu einem Fehler. Weitere Informationen finden Sie in der Dokumentation zu Cloud-Kontingenten.

Zusätzlich zu den Kontingenten und Limits anderer Google Cloud -Dienste gelten für Batch die folgenden Kontingente und Limits, die nicht geändert werden können.

Ratenkontingente

Die folgenden Limits gelten für Batchanfragen. Diese Limits werden als Kontingente angezeigt, z. B. in der Google Cloud Console, können aber nicht erhöht werden.

Limit Wert
Anfragen an den KI-Agenten pro Minute und Region 30.000
Mutationsanfragen pro Minute und Region 6.000
Leseanfragen pro Minute und Region 15.000

Joblimits

Für Batchjobs gelten die folgenden Limits.

Limit Wert
Aufgaben pro Aufgabengruppe 100.000
Parallele Aufgaben pro Job 5.000
Gleichzeitige VMs pro Job in einer einzelnen Zone1 2.000
Gleichzeitige VMs pro Job mit mehreren Zonen1 4.000
Größe der Jobdefinition2 1 MB
Wartezeit (Dauer des Jobstatus QUEUED) vor automatischem Fehler 2 Tage
Laufzeit (Dauer des Jobstatus RUNNING) vor automatischem Fehler3 14 Tage

1 Die Begriffe Einzelzonenjob und Mehrzonenjob beziehen sich hier auf die Anzahl der Zonen, die für die VMs eines Jobs zulässig sind. Diese können sich von den Zonen für den Standort eines Jobs unterscheiden. Weitere Informationen finden Sie unter Batch-Standorte.

2 Beispielsweise ungefähr die Größe der REST-Anfrage an die Methode jobs.create oder die --config-Datei der gcloud CLI. Sie können dieses Limit umgehen, indem Sie die Aufgaben auf mehrere Jobs aufteilen. Weitere Informationen finden Sie unter Abhängige Jobs planen (Vorschau).

3 Für dieses Limit gelten die folgenden Ausnahmen:

  • Wenn Sie das Feld provisioningModel für einen Job auf FLEX_START festlegen, beträgt die maximale Laufzeit vor einem automatischen Fehler stattdessen 7 Tage.
  • Wenn ein Job einen Maschinentyp aus der A3-Serie verwendet, das Feld reservation auf NO_RESERVATION setzt und provisioningModel entweder nicht definiert oder auf STANDARD gesetzt ist, beträgt die maximale Laufzeit vor einem automatischen Fehler stattdessen 7 Tage.
  • Optional können Sie die maximale Laufzeit vor einem automatischen Fehler für einen Job mithilfe von Zeitlimits reduzieren.