Omezení souběžnosti a rychlosti rozhraní API pro fondy Apache Sparku v Azure Synapse Analytics
Následující části obsahují seznam různých číselných omezení pro fondy Sparku a rozhraní API pro správu úloh v Azure Synapse Analytics.
Omezení prostředků
Následující tabulka ukazuje maximální limity úloh a jader pro jednotlivé pracovní prostory a fondy Sparku.
Důležité
Omezení zadaná pro fondy Sparku jsou bez ohledu na jejich velikost uzlů, virtuální jádra a konfiguraci paměti a platí pro všechny vytvořené instance fondu Sparku bez ohledu na uživatele, pokud není uvedeno jinak.
Prostředek | Metric | Omezení | Obor | Oblasti | Poznámky |
---|---|---|---|---|---|
Úlohy | Souběžné spuštění | 50 | Fond Sparku | Vše | Limit platí pro všechny uživatele definice fondu Sparku. Pokud například dva uživatelé odesílají úlohy do stejného fondu Sparku, nesmí kumulativní počet úloh spuštěných pro tyto dva uživatele překročit 50. |
Úlohy | Ve frontě | 200 | Fond Sparku | Vše | Limit platí pro všechny uživatele definice fondu Sparku. |
Úlohy | Maximální počet aktivních úloh | 250 | Fond Sparku | Vše | Limit platí pro všechny uživatele definice fondu Sparku. |
Úlohy | Maximální počet aktivních úloh | 1000 | Pracovní prostor | Vše | |
Cores | Limit počtu jader na uživatele | Na základě definice fondu | Fond Sparku | Vše | Pokud je například fond Sparku definovaný jako fond s 50 jádry, může každý uživatel v rámci konkrétního fondu Sparku použít až 50 jader, protože každý uživatel získá vlastní instanci fondu. |
Cores | Limit počtu jader pro všechny uživatele | Na základě definice pracovního prostoru | Pracovní prostor | Vše | Pokud má například pracovní prostor limit 200 jader, nemůžou všichni uživatelé ve všech fondech v rámci pracovního prostoru používat více než 200 jader dohromady. |
Livy | Maximální velikost datové části pro požadavek Livy | 100 kB | Livy | Vše |
Poznámka
- Maximální počet aktivních úloh je celkový počet odeslaných úloh, který zahrnuje i
Jobs Running Simultaneously
,Jobs Queued
tj.Max Active Jobs = Jobs Running Simultaneously + Jobs Queued
Omezení rychlosti rozhraní API
Následující tabulka ukazuje omezení pro úlohu Sparku a rozhraní API pro správu relací.
Prostředek | Metric | Limit (dotazy za sekundu) | Obor | Oblasti |
---|---|---|---|---|
Rozhraní API pro úlohy | Získat relaci Sparku | 200 | Relace Sparku | Vše |
Rozhraní API pro úlohy | Získat relaci Sparku | 200 | Fond Sparku | Vše |
Rozhraní API pro úlohy | Get Spark – příkaz | 200 | Relace Sparku | Vše |
Rozhraní API pro úlohy | Získání více příkazů Sparku | 200 | Relace Sparku | Vše |
Rozhraní API pro úlohy | Vytvořit relaci | 2 | Pracovní prostor | EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Západní Evropa |
Rozhraní API pro úlohy | Vytvořit relaci | 2 | Pracovní prostor | Všechny ostatní oblasti |
Rozhraní API pro úlohy | Vytvoření dávkové úlohy | 2 | Pracovní prostor | Vše |
Rozhraní API pro úlohy | Získání dávkové úlohy Sparku | 200 | Pracovní prostor | Vše |
Rozhraní API pro úlohy | Získání více dávkových úloh Sparku | 200 | Pracovní prostor | Vše |
Poznámka
Maximální limit požadavků pro všechny prostředky a operace je 200 dotazů za sekundu pro všechny oblasti.
Tip
Pokud se zobrazí chybová zpráva nebo odpověď HTTP 429, která zní:
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)
Nebo
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)
Uživatel by měl použít hodnotu časového období uvedenou v hlavičce odpovědi HTTP Retry-After k čekání na tento časový interval při provádění opakovaných pokusů.Ve scénářích s vysokým provozem by použití náhodného, konstantního nebo exponenciálního časového intervalu pro opakování stále vedlo k chybám HTTP 429 a při vysokém počtu opakování by došlo ke zvýšení celkové doby potřebné k přijetí požadavků službou.
Místo toho by při použití služby poskytované Retry-After hodnotu uživatelé měli při odesílání úloh vyšší míru úspěšnosti, protože hodnota v sekundách se počítá na základě provozu k určitému bodu v čase, aby se optimalizoval počet opakování a doba potřebná k přijetí požadavků klienta serverem.