Limiti di concorrenza e velocità API per i pool Apache Spark in Azure Synapse Analytics

Le sezioni seguenti elencano vari limiti numerici per pool Spark e API per gestire i lavori in Azure Synapse Analytics.

Limiti delle risorse

La tabella seguente mostra i limiti massimi di job e core per singoli workspace e pool Spark.

Importante

I limiti specificati per i pool Spark sono indipendenti dalle dimensioni dei nodi, dalle configurazioni di vCore e memoria e si applicano a tutte le istanze create di un Spark Pool, indipendentemente dall'utente, salvo diversa indicazione.

Risorsa Metrica Limite Scope Regions Note
Jobs Esecuzione simultanea 50 Piscina di Scintille All Il limite si applica a tutti gli utenti di una definizione di Spark Pool. Ad esempio, se due utenti inviano lavori sullo stesso Spark Pool, allora il numero cumulativo di lavori in esecuzione per i due utenti non può superare 50.
Jobs Queued 200 Piscina di Scintille All Il limite si applica a tutti gli utenti di una definizione di Spark Pool.
Jobs Posti di lavoro attivi massimi 250 Piscina di Scintille All Il limite si applica a tutti gli utenti di una definizione di Spark Pool.
Jobs Posti di lavoro attivi massimi 1000 Workspace All
Nuclei Limite di core per utente Basato sulla definizione del pool Piscina di Scintille All Ad esempio, se un pool Spark è definito come un pool da 50 core, ogni utente può utilizzare fino a 50 core all'interno del pool Spark specifico, poiché ogni utente ha la propria istanza del pool.
Nuclei Limiti di core per tutti gli utenti Basato sulla definizione dello spazio di lavoro Workspace All Ad esempio, se uno spazio di lavoro ha un limite di 200 core, allora tutti gli utenti di tutti i pool all'interno dello spazio non possono usare più di 200 core complessivamente.
Livio Dimensione massima del carico utile per la richiesta Livy 100kByte Livio All

Annotazioni

  • Il numero massimo di lavori attivi è il numero totale di offerte di lavoro inviate, che include sia Jobs Running Simultaneously che Jobs Queued, cioè, Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Limiti di frequenza API

La tabella seguente mostra i limiti di throttling per le API di gestione del lavoro e delle sessioni di spark.

Risorsa Metrica Limite (Query al secondo) Scope Regions
API per lavori Ottenere una sessione Spark 200 Sessione Spark All
API per lavori Ottenere una sessione Spark 200 Piscina di Scintille All
API per lavori Ottenere un'istruzione Spark 200 Sessione Spark All
API per lavori Ottieni più estratti conto Spark 200 Sessione Spark All
API per lavori Crea sessione 2 Workspace EstUS, EstUS2, Ovest USA, OvestUS2, CentralUS, EastUS2EUAP, Europa occidentale
API per lavori Crea sessione 2 Workspace Tutte le altre aree
API per lavori Crea un lavoro batch 2 Workspace All
API per lavori Ottenere un processo Batch Spark 200 Workspace All
API per lavori Ottieni un lavoro con più spark batch 200 Workspace All

Annotazioni

Il limite massimo di richieste per tutte le risorse e operazioni è di 200 query al secondo per tutte le regioni.

Tip

Se ricevi un messaggio di errore o una risposta HTTP 429 che dice

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)

O

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 dovrebbe utilizzare il valore del periodo di tempo fornito nell'intestazione di risposta HTTP "Retry-After", per attendere quell'intervallo di tempo durante i tentativi.In scenari ad alto traffico, utilizzare un intervallo di tempo casuale, costante o esponenziale per i tentativi porterebbe comunque a guasti HTTP 429 e comporterebbe un alto numero di tentativi, aumentando così il tempo complessivo necessario per l'accettazione delle richieste dal servizio.

Invece, utilizzando il servizio fornito Retry-After valore, gli utenti avrebbero un tasso di successo più elevato nelle invii di lavoro, poiché il valore in secondi viene calcolato in base al traffico in un momento specifico per ottimizzare il numero di tentativi e il tempo necessario affinché le richieste del client vengano accettate dal server

Passaggi successivi

  • Last updated on