Límites de frecuencia de API y simultaneidad para grupos de Apache Spark en Azure Synapse Analytics

En las secciones siguientes se enumeran varios límites numéricos para grupos y API de Spark para administrar trabajos en Azure Synapse Analytics.

Límites de recursos

En la tabla siguiente se muestran los límites máximos de trabajos y núcleos para áreas de trabajo individuales y grupos de Spark.

Importante

Los límites especificados para los grupos de Spark son independientemente de sus tamaños de nodo, núcleo virtual y configuraciones de memoria, y se aplican a en todas las instancias creadas de un grupo de Spark, independientemente del usuario, a menos que se indique lo contrario.

Resource Métrica Límite Ámbito Regions Notas
Trabajos Ejecución simultánea 50 Grupo de Spark Todo El límite se aplica a todos los usuarios de una definición de grupo de Spark. Por ejemplo, si dos usuarios envían trabajos en el mismo grupo de Spark, el número acumulativo de trabajos que se ejecutan para los dos usuarios no puede superar los 50.
Trabajos En cola 200 Grupo de Spark Todo El límite se aplica a todos los usuarios de una definición de grupo de Spark.
Trabajos Máximo de trabajos activos 250 Grupo de Spark Todo El límite se aplica a todos los usuarios de una definición de grupo de Spark.
Trabajos Máximo de trabajos activos 1000 Área de trabajo All
Núcleos Límite de núcleos por usuario Basado en la definición del grupo Grupo de Spark Todo Por ejemplo, si un grupo de Spark se define como un grupo de 50 núcleos, cada usuario puede usar hasta 50 núcleos dentro del grupo de Spark específico, ya que cada usuario obtiene su propia instancia del grupo.
Núcleos Límite de núcleos en todos los usuarios Basado en la definición del área de trabajo Área de trabajo All Por ejemplo, si un área de trabajo tiene un límite de 200 núcleos, todos los usuarios de todos los grupos del área de trabajo no pueden usar más de 200 núcleos combinados.
Livy Tamaño máximo de la carga útil para la solicitud livy 100kBytes Livy Todo

Nota:

  • El número máximo de trabajos activos es el número total de trabajos enviados, lo que incluye y Jobs Running SimultaneouslyJobs Queued, es decir, Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Límites de frecuencia de la API

En la tabla siguiente se muestran los límites para las API de administración de sesiones y trabajos de Spark.

Resource Métrica Límite (consultas por segundo) Ámbito Regions
API de trabajo Obtener sesión de Spark 200 Sesión de Spark Todo
API de trabajo Obtener sesión de Spark 200 Grupo de Spark Todo
API de trabajo Obtener instrucción Spark 200 Sesión de Spark Todo
API de trabajo Obtención de varias instrucciones spark 200 Sesión de Spark Todo
API de trabajo Crear sesión 2 Área de trabajo EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Oeste de Europa
API de trabajo Crear sesión 2 Área de trabajo Todas las demás regiones
API de trabajo Creación de un trabajo de Batch 2 Área de trabajo All
API de trabajo Obtención del trabajo por lotes de Spark 200 Área de trabajo All
API de trabajo Obtención de varios trabajos por lotes de Spark 200 Área de trabajo All

Nota:

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 recibe un mensaje de error o una respuesta HTTP 429 que lee

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)

Or

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 de período de tiempo proporcionado en el encabezado de respuesta HTTP "Retry-After", para esperar ese intervalo de tiempo al realizar reintentos.En escenarios de tráfico elevado, el uso de un intervalo de tiempo aleatorio, constante o exponencial para los reintentos seguirá provocando errores HTTP 429 y incurrirá en un gran número de reintentos, por lo que aumentará el tiempo total necesario para que el servicio acepte las solicitudes.

En su lugar, mediante el uso del servicio proporcionado Retry-After valor, los usuarios experimentarían una mayor tasa de éxito en los envíos de trabajos, ya que el valor en segundos se calcula en función del tráfico a un momento dado para optimizar el número de reintentos y el tiempo necesario para que el servidor acepte las solicitudes del cliente.

Pasos siguientes