Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die folgenden Abschnitte listen verschiedene numerische Limits für Spark-Pools und APIs zur Verwaltung von Jobs in Azure Synapse Analytics auf.
Ressourcenbeschränkungen
Die folgende Tabelle zeigt die maximalen Limits von Jobs und Kerne für einzelne Arbeitsbereiche und Spark-Pools.
Important
Die für die Spark-Pools festgelegten Limits gelten unabhängig von deren Knotengröße, vCore- und Speicherkonfigurationen und gelten für alle erstellten Instanzen eines Spark Pools, unabhängig vom Benutzer, sofern nicht anders angegeben.
| Resource | Metric | Begrenzung | Geltungsbereich | Regions | Hinweise |
|---|---|---|---|---|---|
| Jobs | Gleichzeitig laufend | 50 | Spark Pool | All | Das Limit gilt für alle Nutzer einer Spark-Pool-Definition. Zum Beispiel, wenn zwei Benutzer Jobs gegen denselben Spark Pool einreichen, darf die kumulierte Anzahl der laufenden Jobs für beide Nutzer nicht 50 überschreiten. |
| Jobs | In der Warteschlange | 200 | Spark Pool | All | Das Limit gilt für alle Nutzer einer Spark-Pool-Definition. |
| Jobs | Maximal aktive Arbeitsplätze | 250 | Spark Pool | All | Das Limit gilt für alle Nutzer einer Spark-Pool-Definition. |
| Jobs | Maximal aktive Arbeitsplätze | 1000 | Arbeitsbereich | All | |
| Kerne | Kernbegrenzung pro Nutzer | Basierend auf der Pool-Definition | Spark Pool | All | Wenn beispielsweise ein Spark-Pool als 50-Kern-Pool definiert ist, kann jeder Benutzer bis zu 50 Kerne innerhalb des spezifischen Spark-Pools verwenden, da jeder Nutzer seine eigene Instanz des Pools erhält. |
| Kerne | Kernbegrenzung für alle Nutzer | Basierend auf der Definition des Arbeitsbereichs | Arbeitsbereich | All | Wenn zum Beispiel ein Arbeitsbereich ein Limit von 200 Kerne hat, dürfen alle Benutzer in allen Pools im Arbeitsbereich nicht mehr als 200 Kerne zusammen verwenden. |
| Livius | Maximale Nutzlastgröße für Livy-Anfrage | 100kBytes | Livius | All |
Note
- Maximal aktive Jobs ist die Gesamtzahl der eingereichten Jobs, die sowohl als auch
Jobs Running SimultaneouslyJobs Queuedumfasst, d. h.Max Active Jobs = Jobs Running Simultaneously + Jobs Queued
API-Ratenbeschränkungen
Die folgende Tabelle zeigt die Drosselungsgrenzen für die Spark-Job- und Session-Management-APIs.
| Resource | Metric | Limit (Abfragen pro Sekunde) | Geltungsbereich | Regions |
|---|---|---|---|---|
| Auftrags-API | Spark-Sitzung abrufen | 200 | Spark-Sitzung | All |
| Auftrags-API | Spark-Sitzung abrufen | 200 | Spark Pool | All |
| Auftrags-API | Get Spark-Anweisung | 200 | Spark-Sitzung | All |
| Auftrags-API | Erhalten Sie mehrere Spark-Statements | 200 | Spark-Sitzung | All |
| Auftrags-API | Sitzung erstellen | 2 | Arbeitsbereich | EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Westeuropa |
| Auftrags-API | Sitzung erstellen | 2 | Arbeitsbereich | Alle anderen Regionen |
| Auftrags-API | Batch-Job erstellen | 2 | Arbeitsbereich | All |
| Auftrags-API | Spark Batchauftrag abrufen | 200 | Arbeitsbereich | All |
| Auftrags-API | Hol dir einen Mehrfach-Spark-Batch-Job | 200 | Arbeitsbereich | All |
Note
Das maximale Anfragelimit für alle Ressourcen und Operationen beträgt 200 Abfragen pro Sekunde für alle Regionen.
Tip
Wenn du eine Fehlermeldung oder eine HTTP-429-Antwort erhältst, liest sich das wie gelesen
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-Antwort-Header "Retry-After" angegebenen Zeitabschnitt verwenden, um dieses Zeitintervall beim Wiederholen zu warten.In Szenarien mit hohem Datenverkehr führt die Verwendung eines zufälligen, konstanten oder exponentiellen Zeitintervalls für die Wiederholungen weiterhin zu HTTP-429-Ausfällen und tritt bei einer hohen Anzahl von Wiederholungen auf, wodurch die Gesamtzeit für die Annahme der Anfragen durch den Dienst erhöht wird.
Stattdessen würden Nutzer durch die Nutzung des bereitgestellten Dienstes Retry-After Wert eine höhere Erfolgsquote bei Job-Einsendungen erzielen, da der Wert in Sekunden basierend auf dem zeitlichen Datenverkehr berechnet wird, um die Anzahl der Wiederholungen und die Zeit, die für die Annahme von Client-Anfragen vom Server benötigt wird, zu optimieren