Für Managed Service for Apache Spark gelten API-Kontingentlimits, die auf Projekt- und Regionsebene erzwungen werden. Die Kontingente werden alle 60 Sekunden (1 Minute) zurückgesetzt.

Umgang mit Kontingentfehlern für Managed Service for Apache Spark: Wenn Sie ein Kontingentlimit für Managed Service for Apache Spark überschreiten, wird ein RESOURCE_EXHAUSTED-Fehler (HTTP-Code 429) generiert und die entsprechende Managed Service for Apache Spark API-Anfrage schlägt fehl. Da das Managed Service for Apache Spark-Kontingent Ihres Projekts jedoch alle 60 Sekunden aktualisiert wird, können Sie die Anfrage nach einer Minute wiederholen.

In der folgenden Tabelle sind die spezifischen und standardmäßigen Kontingenttypen, Kontingentlimits und die Methoden aufgeführt, für die sie gelten, für die Managed Service for Apache Spark API pro Projekt.

Kontingenttyp	Limit	API-Methoden oder Beschreibung
ClusterOperationRequestsPerMinutePerProjectPerRegion	200	CancelOperation (das Kontingent für das Abbrechen von Batchvorgängen wird mit dem Kontingent für das Abbrechen von Clustervorgängen geteilt).
BatchOperationRequestsPerMinutePerProjectPerRegion	200	CreateBatch, DeleteBatch
SessionOperationRequestsPerMinutePerProjectPerRegion	200	CreateSession, DeleteSession, TerminateSession
DefaultRequestsPerMinutePerProjectPerRegion	7.500	GetBatch, ListBatches, GetSession, ListSessions
ActiveOperationsPerProjectPerRegion	5.000	Begrenzung der Gesamtzahl gleichzeitiger aktiver Vorgänge aller Typen in einem Projekt in einer Region.

Ressourcenkontingentlimits erhöhen: Öffnen Sie die SeiteGoogle Cloud Identity and Access Management (IAM) und Verwaltung – Kontingente und wählen Sie die Ressourcen aus, die Sie ändern möchten. Klicken Sie dann oben auf der Seite auf Kontingente bearbeiten, um den Vorgang zur Kontingenterhöhung zu starten.

Serverloses DCU-Kontingent für Managed Service for Apache Spark

Ab der serverlosen Laufzeitversion 4.0 von Managed Service for Apache Spark wird die Nutzung von Rechenressourcen für serverlose Batcharbeitslasten und interaktive Sitzungen von Managed Service for Apache Spark durch das Data Compute Unit-Kontingent (DCU) eines Projekts (dataproc.googleapis.com/data_compute_units) anstelle des Compute Engine-Kontingents verwaltet und begrenzt. Die zugrunde liegende Nutzung des Compute Engine-Kontingents wird an ein dediziertes Producer-Projekt von Managed Service for Apache Spark weitergeleitet.

Sie können Ihr DCU-Kontingent in der Dataproc API in der Google Cloud Console auf der Seite Kontingente aufrufen und anpassen. Sie können die Kontingentanpassung aktivieren, um Ihr DCU-Kontingent zu erhöhen, wenn Ihre Nutzung das Limit erreicht.

Hinweis: Wenn Sie die serverlose Laufzeitversion „4.0“ von Managed Service for Apache Spark einrichten, achten Sie darauf, dass Sie ein ausreichendes DCU-Kontingent für die erwartete Arbeitslastgröße und die Anzahl der gleichzeitigen Sitzungen/Batches haben.

DCU-Verbrauch berechnen

Die DCU-Nutzung wird pro Knoten anhand der VM-Form berechnet. Dabei wird dieselbe Formel wie für die DCU-Preise für Managed Service for Apache Spark Serverless verwendet:

• 0,6 DCU pro vCPU.
• 0,1 DCU pro GB Arbeitsspeicher, bis zu 8 GB pro vCPU.
• 0,2 DCU pro GB Arbeitsspeicher über 8 GB pro vCPU (erweiterter Arbeitsspeicher).
• Knoten der Premium-Stufe zählen 1,5-mal so viele DCUs wie Knoten derselben Form in der Standardstufe.

Die DCUs eines Knotenpools werden auf die nächste Ganzzahl aufgerundet:

DCUs = ceiling(nodes × DCUs per node)

Beispiel: Ein Knoten der Standardstufe mit 4 vCPUs und 16 GB Arbeitsspeicher verwendet 4 × 0.6 + 16 × 0.1 = 4 DCUs. Ein Batch mit einem Treiber und zehn Executors dieser Form verwendet 44 DCUs. Derselbe Batch in der Premium-Stufe verwendet 66 DCUs.

Beschränkungen

Für DCU-Kontingente gelten die folgenden Einschränkungen:

• Laufzeitversionen: DCU-Kontingente gelten für die serverlose Managed Service for Apache Spark-Laufzeitversion 4.0 und höher. Arbeitslasten, die Laufzeitversionen vor 4.0 verwenden, verbrauchen kein DCU-Kontingent und verbrauchen weiterhin das Compute Engine-Kontingent eines Projekts.
• Nicht unterstützte Kontingente: GPU-, Reservierungs- und globale Compute Engine-Kontingente werden im DCU-Kontingentmodell nicht unterstützt.

Andere Google Cloud Kontingente

Managed Service for Apache Spark-Batches verwenden andere Google Cloud -Produkte. Diese Produkte haben Kontingente auf Projektebene, einschließlich Kontingenten, die für die Nutzung von Managed Service for Apache Spark gelten. Einige Dienste sind für die Verwendung von Managed Service for Apache Spark erforderlich, z. B. Compute Engine und Cloud Storage. Andere Dienste wie BigQuery und Bigtable können optional mit Managed Service for Apache Spark verwendet werden.

Erforderliche Dienste

Die folgenden Dienste, die Kontingentlimits erzwingen, sind erforderlich, um Managed Service for Apache Spark-Batches zu erstellen.

Compute Engine

Hinweis: Die in diesem Abschnitt erwähnten Compute Engine-Kontingente sind für die Laufzeitversion 4.0 und höher nicht erforderlich. Weitere Informationen finden Sie unter DCU-Kontingent.

Für Managed Service for Apache Spark-Batcharbeitslasten können verschiedene Compute Engine-Ressourcen ausgewählt werden:

• Um Probleme mit der Verfügbarkeit von CPUs und Laufwerken zu minimieren, unterstützt Managed Service for Apache Spark Fallbacks über mehrere Maschinenfamilien und Laufwerkstypen hinweg. In der Premium-Stufe kann eine Batcharbeitslast beispielsweise auf N2 mit nichtflüchtigem SSD-Speicher, N2D mit lokaler SSD, N2D mit nichtflüchtigem Speicher, N4 mit Hyperdisk Balanced oder N4D mit Hyperdisk Balanced zurückgreifen.

• Eine Batcharbeitslast schlägt fehl, wenn das Kontingent nicht ausreicht, um die Ressourcen der Fallback-Auswahl zu nutzen.

In der folgenden Tabelle sind die Compute Engine-Ressourcenkontingente aufgeführt, die für Managed Service for Apache Spark-Batcharbeitslasten gelten.

Computing-Stufe	Kontingent
Standard	CPUS
Premium	N2_CPUS N2D_CPUS CPUS_PER_VM_FAMILY mit N4-VM-Familie CPUS_PER_VM_FAMILY mit N4D-VM-Familie
Laufwerksstufe	Kontingent
Standard	DISKS_TOTAL_GB
Premium	DISKS_TOTAL_GB LOCAL_SSD_TOTAL_GB_PER_VM_FAMILY mit N2- und N2D-VM-Familien SSD-TOTAL-GB oder Persistent Disk SSD (GB) HDB-TOTAL-GB oder Hyperdisk Balanced Capacity (GB)
GPU-Beschleuniger	Kontingent
L4	NVIDIA_L4_GPUS
A100 40GB	NVIDIA_A100_GPUS
A100 80GB	NVIDIA_A100_80GB_GPUS

Die Compute Engine-Kontingente sind in regionale und globale Limits unterteilt. Diese Limits gelten für Batches, die Sie erstellen. Wenn Sie beispielsweise einen Spark-Batch mit 4 Treiberkernen (spark.driver.cores=4) und zwei Executors mit jeweils 4 Kernen (spark.executor.cores=4) ausführen, verwenden Sie 12 virtuelle CPUs (4 * 3). Diese Batchnutzung wird auf das regionale Kontingentlimit von 24 virtuellen CPUs angerechnet.

Kostenlose Testkontingente: Wenn Sie die kostenlose Testversion von Compute Engine verwenden, hat Ihr Projekt ein Limit von 8 CPUs. Sie müssen die Abrechnung im Projekt aktivieren, um dieses Limit zu erhöhen.

Standard-Batch-Ressourcen

Wenn Sie einen Batch mit Standardeinstellungen erstellen, werden die folgenden Compute Engine-Ressourcen verwendet:

Posten	Verwendete Ressourcen
Virtuelle CPUs	12
VM-Instanzen	3
Nichtflüchtiger Speicher	1.200 GiB

Logging

Managed Service for Apache Spark speichert Batchausgaben und Logs in Cloud Logging. Das Logging-Kontingent gilt für Ihre Managed Service for Apache Spark-Batches.

Optionale Dienste

Die folgenden Dienste, für die Kontingentlimits gelten, können optional mit Managed Service for Apache Spark-Batches verwendet werden.

BigQuery

Beim Lesen oder Schreiben von Daten in BigQuery gilt das BigQuery-Kontingent.

Bigtable

Beim Lesen oder Schreiben von Daten in Bigtable gilt das Bigtable-Kontingent.

Arbeitslasten mit Kontingent- oder IP-Adressbeschränkungen identifizieren

Mit den folgenden Logging-Abfragen können Sie Managed Service for Apache Spark-Arbeitslasten identifizieren, die Ihr Kontingent erreicht haben oder aufgrund von IP-Adressenmangel nicht skaliert werden konnten.

Kontingentabfrage:

jsonPayload.@type="type.googleapis.com/google.cloud.dataproc.logging.AutoscalerLog"