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 QueuedauchJobs Running Simultaneouslyumfasst, 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.