Freigeben über


Grenzwerte für Parallelität und API-Raten für Apache Spark-Pools in Azure Synapse Analytics

In den folgenden Abschnitten werden verschiedene numerische Grenzwerte für Spark-Pools und -APIs zum Verwalten von Aufträgen in Azure Synapse Analytics aufgeführt.

Ressourceneinschränkungen

In der folgenden Tabelle sind die maximalen Grenzwerte für Aufträge und Kerne für einzelne Arbeitsbereiche und Spark-Pools aufgeführt.

Wichtig

Die für die Spark-Pools angegebenen Grenzwerte gelten unabhängig von knotengrößen, virtuellen Kernen und Arbeitsspeicherkonfigurationen und gelten unabhängig vom Benutzer für alle erstellten Instanzen eines Spark-Pools, sofern nichts anderes angegeben ist.

Resource Metrik Begrenzung `Scope` Regions Notizen
Aufträge Gleichzeitiges Ausführen 50 Spark-Pool Alle Der Grenzwert gilt für alle Benutzer einer Spark-Pooldefinition. Wenn beispielsweise zwei Benutzer Aufträge für denselben Spark-Pool übermitteln, darf die kumulative Anzahl von Aufträgen, die für die beiden Benutzer ausgeführt werden, 50 nicht überschreiten.
Aufträge In Warteschlange 200 Spark-Pool Alle Der Grenzwert gilt für alle Benutzer einer Spark-Pooldefinition.
Aufträge Maximal aktive Aufträge 250 Spark-Pool Alle Der Grenzwert gilt für alle Benutzer einer Spark-Pooldefinition.
Aufträge Maximal aktive Aufträge 1000 Arbeitsbereich All
Kerne Cores Limit pro Benutzer Basierend auf der Pooldefinition Spark-Pool Alle Wenn beispielsweise ein Spark-Pool als Pool mit 50 Kernen definiert ist, kann jeder Benutzer bis zu 50 Kerne innerhalb des jeweiligen Spark-Pools verwenden, da jeder Benutzer seine eigene instance des Pools erhält.
Kerne Kerngrenzwert für alle Benutzer Basierend auf der Arbeitsbereichsdefinition Arbeitsbereich All Wenn ein Arbeitsbereich beispielsweise auf 200 Kerne beschränkt ist, können alle Benutzer in allen Pools innerhalb des Arbeitsbereichs nicht mehr als 200 Kerne zusammen verwenden.
Livy Maximale Nutzlastgröße für Livy-Anforderung 100 KB Livy All

Hinweis

  • Maximum Active Jobs ist die Gesamtzahl der übermittelten Aufträge, die sowohl als Jobs Queuedauch Jobs Running Simultaneously umfasst, d. h.Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

API-Ratenbegrenzungen

In der folgenden Tabelle sind die Drosselungsgrenzwerte für die Spark-Auftrags- und Sitzungsverwaltungs-APIs aufgeführt.

Resource Metrik Grenzwert (Abfragen pro Sekunde) `Scope` Regions
Auftrags-API Abrufen einer Spark-Sitzung 200 Spark-Sitzung Alle
Auftrags-API Abrufen einer Spark-Sitzung 200 Spark-Pool Alle
Auftrags-API Spark-Anweisung abrufen 200 Spark-Sitzung Alle
Auftrags-API Abrufen mehrerer Spark-Anweisungen 200 Spark-Sitzung Alle
Auftrags-API Sitzung erstellen 2 Arbeitsbereich EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Europa, Westen
Auftrags-API Sitzung erstellen 2 Arbeitsbereich Alle anderen Regionen
Auftrags-API Erstellen eines Batchauftrags 2 Arbeitsbereich All
Auftrags-API Abrufen eines Spark-Batchauftrags 200 Arbeitsbereich All
Auftrags-API Abrufen mehrerer Spark-Batchaufträge 200 Arbeitsbereich All

Hinweis

Das maximale Anforderungslimit für alle Ressourcen und Vorgänge beträgt 200 Abfragen pro Sekunde für alle Regionen.

Tipp

Wenn Sie eine Fehlermeldung oder eine HTTP 429-Antwort erhalten, die liest

Your request has hit layered throttling rate-limit of 200 requests per 1 second(s) for requests on resource(s) identified by pattern {subscriptionId}. {workspaceName}. {HTTP-Verb}. {operationName} - You are currently hitting at a rate of 282 requests per 1 second(s). Please retry after 1 second(s)

oder

Your request has hit layered throttling rate-limit of 2 requests per 1 second(s) for requests on resource(s) identified by {subscriptionId}. {workspaceName}. {HTTP-Verb}. {operationName} - You are currently hitting at a rate of 24 requests per 1 second(s). Please retry after 1 second(s)

Der Benutzer sollte den im HTTP-Antwortheader "Retry-After" angegebenen Zeitraum verwenden, um beim Ausführen von Wiederholungen auf dieses Zeitintervall zu warten.In Szenarien mit hohem Datenverkehr würde die Verwendung eines zufälligen, konstanten oder exponentiellen Zeitintervalls für die Wiederholungsversuche immer noch zu HTTP 429-Fehlern führen und eine hohe Anzahl von Wiederholungen verursachen, indem die Gesamtdauer erhöht wird, die für die Akzeptanz der Anforderungen durch den Dienst erforderlich ist.

Durch die Verwendung des Retry-After-Werts bereitgestellten Diensts würden Benutzer eine höhere Erfolgsrate bei Auftragsübermittlungen erleben, da der Wert in Sekunden basierend auf dem Zeitpunktdatenverkehr berechnet wird, um die Anzahl der Wiederholungen und die Zeit zu optimieren, die benötigt wird, bis die Anforderungen des Clients vom Server akzeptiert werden.

Nächste Schritte