Samtidighets- och API-hastighetsgränser för Apache Spark-pooler i Azure Synapse Analytics

  • Artikel

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 Simultaneously och Jobs 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

Nästa steg