Samtidighets- och API-hastighetsgränser för Apache Spark-pooler i Azure Synapse Analytics
I följande avsnitt visas olika numeriska gränser för Spark-pooler och API:er för att hantera jobb i Azure Synapse Analytics.
Resursgränser
I följande tabell visas de maximala gränserna för jobb och kärnor för enskilda arbetsytor och Spark-pooler.
Viktigt
De gränser som anges för Spark-poolerna är oberoende av nodstorlekar, virtuella kärnor och minneskonfigurationer och gäller för alla skapade instanser av en Spark-pool oavsett användaren om inget annat anges.
| Resurs | Metric | Gräns | Omfång | Regioner | Kommentarer |
|---|---|---|---|---|---|
| Jobb | Körs samtidigt | 50 | Spark-pool | Alla | Gränsen gäller för alla användare av en Spark-pooldefinition. Om två användare till exempel skickar jobb mot samma Spark-pool får det kumulativa antalet jobb som körs för de två användarna inte överstiga 50. |
| Jobb | I kö | 200 | Spark-pool | Alla | Gränsen gäller för alla användare av en Spark-pooldefinition. |
| Jobb | Maximalt antal aktiva jobb | 250 | Spark-pool | Alla | Gränsen gäller för alla användare av en Spark-pooldefinition. |
| Jobb | Maximalt antal aktiva jobb | 1000 | Arbetsyta | Alla | |
| Kärnor | Gräns för kärnor per användare | Baserat på pooldefinitionen | Spark-pool | Alla | Om en Spark-pool till exempel definieras som en pool med 50 kärnor kan varje användare använda upp till 50 kärnor i den specifika Spark-poolen, eftersom varje användare får en egen instans av poolen. |
| Kärnor | Gräns för kärnor för alla användare | Baserat på arbetsytedefinition | Arbetsyta | Alla | Om en arbetsyta till exempel har en gräns på 200 kärnor kan alla användare i alla pooler på arbetsytan inte använda fler än 200 kärnor tillsammans. |
| Livy | Maximal nyttolaststorlek för Livy-begäran | 100 kByte | Livy | Alla |
Anteckning
- Maximalt antal aktiva jobb är det totala antalet skickade jobb, vilket omfattar både
Jobs Running SimultaneouslyochJobs Queued, d.v.s.Max Active Jobs = Jobs Running Simultaneously + Jobs Queued
API-hastighetsbegränsningar
I följande tabell visas begränsningsgränserna för SPARK-jobb- och sessionshanterings-API:erna.
| Resurs | Metric | Gräns (frågor per sekund) | Omfång | Regioner |
|---|---|---|---|---|
| API:er för jobb | Hämta Spark-session | 200 | Spark-session | Alla |
| API:er för jobb | Hämta Spark-session | 200 | Spark-pool | Alla |
| API:er för jobb | Hämta Spark-instruktion | 200 | Spark-session | Alla |
| API:er för jobb | Hämta flera Spark-instruktioner | 200 | Spark-session | Alla |
| API:er för jobb | Skapa session | 2 | Arbetsyta | EASTUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Europa, västra |
| API:er för jobb | Skapa session | 2 | Arbetsyta | Alla andra regioner |
| API:er för jobb | Skapa Batch-jobb | 2 | Arbetsyta | Alla |
| API:er för jobb | Hämta Spark Batch-jobb | 200 | Arbetsyta | Alla |
| API:er för jobb | Hämta flera Spark Batch-jobb | 200 | Arbetsyta | Alla |
Anteckning
Den maximala gränsen för begäranden för alla resurser och åtgärder är 200 frågor per sekund för alla regioner.
Tips
Om du får ett felmeddelande eller HTTP 429-svar som läser
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)
Eller
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)
Användaren bör använda tidsperiodvärdet som anges i HTTP-svarshuvudet "Försök igen" för att vänta på det tidsintervallet när återförsök utförs.I scenarier med hög trafik skulle användning av ett slumpmässigt, konstant eller exponentiellt tidsintervall för återförsöken fortfarande resultera i HTTP 429-fel och kommer att medföra ett stort antal återförsök, där genom att öka den totala tid det tar för begäranden att accepteras av tjänsten.
Genom att använda tjänsten som tillhandahålls Retry-After värde skulle användarna i stället uppleva högre resultat i jobböverföringar eftersom värdet i sekunder beräknas baserat på tidstrafik för att optimera antalet återförsök och den tid det tar för klientens begäranden att accepteras av servern