Limiti di concorrenza e frequenza API per i pool di Apache Spark in Azure Synapse Analytics
Le sezioni seguenti elencano vari limiti numerici per i pool di Spark e le API per gestire i processi in Azure Synapse Analytics.
Limiti delle risorse
La tabella seguente illustra i limiti massimi di processi e core per singole aree di lavoro e pool di Spark.
Importante
I limiti specificati per i pool di Spark sono indipendentemente dalle dimensioni dei nodi, dalle configurazioni vCore e dalla memoria e applicate a tutte le istanze create di un pool di Spark indipendentemente dall'utente, se non diversamente specificato.
| Risorsa | Metrica | Limite | Scope | Regioni | Note |
|---|---|---|---|---|---|
| Processi | Esecuzione simultanea | 50 | Pool di Spark | Tutti | Il limite si applica a tutti gli utenti di una definizione di pool di Spark. Ad esempio, se due utenti inviano processi sullo stesso pool di Spark, il numero cumulativo di processi in esecuzione per i due utenti non può superare 50. |
| Processi | Queued | 200 | Pool di Spark | Tutti | Il limite si applica a tutti gli utenti di una definizione di pool di Spark. |
| Processi | Numero massimo di processi attivi | 250 | Pool di Spark | Tutti | Il limite si applica a tutti gli utenti di una definizione di pool di Spark. |
| Processi | Numero massimo di processi attivi | 1000 | Area di lavoro | Tutti | |
| Core | Limite di core per utente | In base alla definizione del pool | Pool di Spark | Tutti | Ad esempio, se un pool di Spark è definito come pool di 50 core, ogni utente può usare fino a 50 core all'interno del pool di Spark specifico, poiché ogni utente ottiene la propria istanza del pool. |
| Core | Limite di core per tutti gli utenti | In base alla definizione dell'area di lavoro | Area di lavoro | Tutti | Ad esempio, se un'area di lavoro ha un limite di 200 core, tutti gli utenti in tutti i pool all'interno dell'area di lavoro non possono usare più di 200 core combinati. |
| Livy | Dimensioni massime del payload per la richiesta Livy | 100.000 byte | Livy | Tutti |
Nota
- Il numero massimo di processi attivi è il numero totale di processi inviati, che include sia che
Jobs Running SimultaneouslyJobs Queued, ad esempioMax Active Jobs = Jobs Running Simultaneously + Jobs Queued
Limiti di frequenza API
La tabella seguente illustra i limiti di limitazione per le API di gestione del processo Spark e della sessione.
| Risorsa | Metrica | Limite (query al secondo) | Scope | Regioni |
|---|---|---|---|---|
| API per processi | Ottenere una sessione Spark | 200 | Sessione Spark | Tutti |
| API per processi | Ottenere una sessione Spark | 200 | Pool di Spark | Tutti |
| API per processi | Ottenere l'istruzione Spark | 200 | Sessione Spark | Tutti |
| API per processi | Ottenere più istruzioni Spark | 200 | Sessione Spark | Tutti |
| API per processi | Crea sessione | 2 | Area di lavoro | EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Europa occidentale |
| API per processi | Crea sessione | 2 | Area di lavoro | Tutte le altre aree |
| API per processi | Creare un processo batch | 2 | Area di lavoro | Tutti |
| API per processi | Ottenere il processo Batch Spark | 200 | Area di lavoro | Tutti |
| API per processi | Ottenere più processi batch Spark | 200 | Area di lavoro | Tutti |
Nota
Il limite massimo di richieste per tutte le risorse e le operazioni è di 200 query al secondo per tutte le aree.
Suggerimento
Se viene visualizzato un messaggio di errore o una risposta HTTP 429 che legge
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)
Oppure
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)
L'utente deve usare il valore del periodo di tempo fornito nell'intestazione di risposta HTTP "Retry-After", per attendere tale intervallo di tempo durante l'esecuzione dei tentativi.Negli scenari di traffico elevato, l'uso di un intervallo di tempo casuale, costante o esponenziale per i tentativi comporta comunque errori HTTP 429 e incorrerà in un numero elevato di tentativi, aumentando il tempo complessivo impiegato per le richieste di accettare dal servizio.
Invece usando il servizio fornito Retry-After valore, gli utenti avrebbero avuto una maggiore frequenza di successo negli invii di processi perché il valore in secondi viene calcolato in base al traffico temporizzato per ottimizzare il numero di tentativi e tempo impiegato per le richieste del client da accettare dal server