Límites de concurrencia y tasa API para pools Apache Spark en Azure Synapse Analytics

Las siguientes secciones enumeran varios límites numéricos para pools y APIs de Spark para gestionar trabajos en Azure Synapse Analytics.

Límites de recursos

La siguiente tabla muestra los límites máximos de trabajos y núcleos para espacios de trabajo individuales y pools de Spark.

Importante

Los límites especificados para los pools de Spark son independientes de sus tamaños de nodos, vCore y configuraciones de memoria y se aplican a todas las instancias creadas de un Spark Pool, independientemente del usuario, salvo que se indique lo contrario.

Resource Métrica Límite Ámbito Regions Notas
Jobs Funcionando simultáneamente 50 Piscina Chispa Todos El límite se aplica a todos los usuarios de una definición de Spark Pool. Por ejemplo, si dos usuarios están enviando trabajos contra el mismo Spark Pool, entonces el número acumulado de trabajos ejecutados para ambos usuarios no puede superar los 50.
Jobs En cola 200 Piscina Chispa Todos El límite se aplica a todos los usuarios de una definición de Spark Pool.
Jobs Empleos Activos Máximos 250 Piscina Chispa Todos El límite se aplica a todos los usuarios de una definición de Spark Pool.
Jobs Empleos Activos Máximos 1000 Área de trabajo Todos
Núcleos Límite de núcleos por usuario Basado en la definición del grupo Piscina Chispa Todos Por ejemplo, si un pool Spark se define como un pool de 50 núcleos, cada usuario puede usar hasta 50 núcleos dentro del pool específico de Spark, ya que cada usuario obtiene su propia instancia del pool.
Núcleos Límite de núcleos para todos los usuarios Basado en la definición del espacio de trabajo Área de trabajo Todos Por ejemplo, si un espacio de trabajo tiene un límite de 200 núcleos, entonces todos los usuarios de todos los grupos dentro del espacio de trabajo no pueden usar más de 200 núcleos en conjunto.
Livio Tamaño máximo de carga útil para la solicitud de Livy 100kBytes Livio Todos

Note

  • El número máximo de empleos activos es el número total de puestos enviados, que incluye tanto Jobs Running Simultaneously como Jobs Queued, es decir, Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Límites de velocidad de API

La siguiente tabla muestra los límites de limitación para las APIs de gestión de trabajos y sesiones de spark.

Resource Métrica Límite (Consultas por segundo) Ámbito Regions
API de trabajos Obtener sesión de Spark 200 Sesión de Spark Todos
API de trabajos Obtener sesión de Spark 200 Piscina Chispa Todos
API de trabajos Get Spark (instrucción) 200 Sesión de Spark Todos
API de trabajos Consigue varias declaraciones de chispa 200 Sesión de Spark Todos
API de trabajos Crear sesión 2 Área de trabajo EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Europa Occidental
API de trabajos Crear sesión 2 Área de trabajo Todas las demás regiones
API de trabajos Crear trabajo por lotes 2 Área de trabajo Todos
API de trabajos Obtención del trabajo de Spark Batch 200 Área de trabajo Todos
API de trabajos Consigue un trabajo en lotes de varias chispas 200 Área de trabajo Todos

Note

El límite máximo de solicitudes para todos los recursos y operaciones es de 200 consultas por segundo para todas las regiones.

Sugerencia

Si recibes un mensaje de error o una respuesta HTTP 429 que 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)

El usuario debe usar el valor del periodo de tiempo proporcionado en la cabecera de respuesta HTTP "Retry-After" para esperar ese intervalo de tiempo al realizar intentos.En escenarios de alto tráfico, usar un intervalo de tiempo aleatorio, constante o exponencial para los intentos seguiría resultando en fallos de HTTP 429 y provocaría un gran número de intentos, aumentando así el tiempo total necesario para que las solicitudes sean aceptadas por el servicio.

En su lugar, al usar el servicio proporcionado Retry-After valor, los usuarios experimentarían una mayor tasa de éxito en las entregas de trabajos, ya que el valor en segundos se calcula en función del tráfico en un momento para optimizar el número de intentos y el tiempo que tarda en aceptar las solicitudes del cliente por parte del servidor

Pasos siguientes

  • Last updated on