Gelijktijdigheids- en API-frequentielimieten voor Apache Spark-pools in Azure Synapse Analytics
De volgende secties bevatten verschillende numerieke limieten voor Spark-pools en API's voor het beheren van taken in Azure Synapse Analytics.
Bronlimieten
In de volgende tabel ziet u de maximumlimieten voor taken en kernen voor afzonderlijke werkruimten en Spark-pools.
Belangrijk
De limieten die zijn opgegeven voor de Spark-pools zijn onafhankelijk van hun knooppuntgrootten, vCore en geheugenconfiguraties en zijn van toepassing op alle gemaakte exemplaren van een Spark-pool, ongeacht de gebruiker, tenzij anders vermeld.
| Resource | Metrisch | Limiet | Bereik | Regio's | Notities |
|---|---|---|---|---|---|
| Taken | Gelijktijdig uitvoeren | 50 | Spark-pool | Alles | Limiet geldt voor alle gebruikers van een definitie van een Spark-pool. Als bijvoorbeeld twee gebruikers taken indienen voor dezelfde Spark-pool, kan het cumulatieve aantal taken dat voor de twee gebruikers wordt uitgevoerd, niet groter zijn dan 50. |
| Taken | In wachtrij | 200 | Spark-pool | Alles | Limiet geldt voor alle gebruikers van een definitie van een Spark-pool. |
| Taken | Maximum aantal actieve taken | 250 | Spark-pool | Alles | Limiet geldt voor alle gebruikers van een definitie van een Spark-pool. |
| Taken | Maximum aantal actieve taken | 1000 | Werkruimte | Alles | |
| Kernen | Limiet voor kernen per gebruiker | Op basis van de pooldefinitie | Spark-pool | Alles | Als een Spark-pool bijvoorbeeld is gedefinieerd als een pool van 50 kernen, kan elke gebruiker maximaal 50 kernen binnen de specifieke Spark-pool gebruiken, omdat elke gebruiker een eigen exemplaar van de pool krijgt. |
| Kernen | Kernlimiet voor alle gebruikers | Op basis van werkruimtedefinitie | Werkruimte | Alles | Als een werkruimte bijvoorbeeld een limiet van 200 kernen heeft, kunnen alle gebruikers in alle pools binnen de werkruimte niet meer dan 200 kernen samen gebruiken. |
| Livy | Maximale nettoladinggrootte voor Livy-aanvraag | 100 kB | Livy | Alles |
Notitie
- Maximum aantal actieve taken is het totale aantal verzonden taken, inclusief en
Jobs Running SimultaneouslyJobs Queued, dat wil zeggenMax Active Jobs = Jobs Running Simultaneously + Jobs Queued
API-frequentielimieten
De volgende tabel toont de beperkingslimieten voor de SPARK-taak en sessiebeheer-API's.
| Resource | Metrisch | Limiet (query's per seconde) | Bereik | Regio's |
|---|---|---|---|---|
| Taken-API | Spark-sessie ophalen | 200 | Spark-sessie | Alles |
| Taken-API | Spark-sessie ophalen | 200 | Spark-pool | Alles |
| Taken-API | Spark-instructie ophalen | 200 | Spark-sessie | Alles |
| Taken-API | Meerdere Spark-instructies ophalen | 200 | Spark-sessie | Alles |
| Taken-API | Sessie maken | 2 | Werkruimte | EastUS, EastUS2, WestUS2, WestUS2, CentralUS, EastUS2EUAP, Europa - west |
| Taken-API | Sessie maken | 2 | Werkruimte | Alle andere regio's |
| Taken-API | Batch-taak maken | 2 | Werkruimte | Alles |
| Taken-API | Spark Batch-taak ophalen | 200 | Werkruimte | Alles |
| Taken-API | Meerdere Spark-batchtaken ophalen | 200 | Werkruimte | Alles |
Notitie
De maximale aanvraaglimiet voor alle resources en bewerkingen is 200 query's per seconde voor alle regio's.
Tip
Als u een foutbericht of HTTP 429-antwoord krijgt dat wordt gelezen
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)
of
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)
De gebruiker moet de waarde voor de tijdsperiode gebruiken die is opgegeven in de HTTP-antwoordheader 'Opnieuw proberen', om te wachten op dat tijdsinterval bij het uitvoeren van nieuwe pogingen.In scenario's met veel verkeer zou het gebruik van een willekeurig, constant of exponentieel tijdsinterval voor de nieuwe pogingen nog steeds leiden tot HTTP 429-fouten en zal dit optreden in een groot aantal nieuwe pogingen, waarbij de totale tijd die nodig is om de aanvragen te accepteren door de service te verhogen.
In plaats daarvan zouden gebruikers met behulp van de service die Retry-After waarde is geleverd, een hoger slagingspercentage ervaren bij het indienen van taken, omdat de waarde in seconden wordt berekend op basis van verkeer op een bepaald tijdstip om het aantal nieuwe pogingen en de tijd die nodig is om aanvragen van de client te accepteren door de server te optimaliseren