Limites de concurrence et de taux API pour les pools Apache Spark dans Azure Synapse Analytics

Les sections suivantes listent diverses limites numériques pour les pools Spark et les API afin de gérer les emplois dans Azure Synapse Analytics.

Limites des ressources

Le tableau suivant montre les limites maximales des jobs et des cœurs pour les espaces de travail individuels et les pools Spark.

Important

Les limites spécifiées pour les pools Spark sont indépendantes de la taille de leurs nœuds, de leur vCore et de leurs configurations mémoire, et s’appliquent à toutes les instances créées d’un pool Spark, quel que soit l’utilisateur, sauf indication contraire.

Ressource Metric Limite Scope Regions Remarques
Jobs Exécution simultanée 50 Piscine d’étincelles All La limite s’applique à tous les utilisateurs d’une définition de Spark Pool. Par exemple, si deux utilisateurs soumettent des tâches sur le même Spark Pool, alors le nombre cumulé de tâches exécutées pour ces deux utilisateurs ne peut pas dépasser 50.
Jobs Mis en file d’attente 200 Piscine d’étincelles All La limite s’applique à tous les utilisateurs d’une définition de Spark Pool.
Jobs Emplois actifs maximaux 250 Piscine d’étincelles All La limite s’applique à tous les utilisateurs d’une définition de Spark Pool.
Jobs Emplois actifs maximaux 1000 Espace de travail All
Cœurs Limite de cœurs par utilisateur Basé sur la définition du pool Piscine d’étincelles All Par exemple, si un pool Spark est défini comme un pool de 50 cœurs, chaque utilisateur peut utiliser jusqu’à 50 cœurs au sein du pool Spark spécifique, puisque chaque utilisateur dispose de sa propre instance du pool.
Cœurs Limite de cœurs pour tous les utilisateurs Basé sur la définition de l’espace de travail Espace de travail All Par exemple, si un espace de travail a une limite de 200 cœurs, alors tous les utilisateurs de tous les pools de l’espace de travail ne peuvent pas utiliser plus de 200 cœurs réunis.
Tite-Live Taille maximale de charge utile pour la demande Livy 100kOctets Tite-Live All

Note

  • Le nombre maximal d’emplois actifs est le nombre total d’emplois soumis, qui inclut à la fois Jobs Running Simultaneously et Jobs Queued, c’est-à-dire : Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Limites de débit d’API

Le tableau suivant montre les limites de limitation des API de gestion des jobs et sessions Spark.

Ressource Metric Limite (requêtes par seconde) Scope Regions
API Travaux Obtenir une session Spark 200 Spark Session All
API Travaux Obtenir une session Spark 200 Piscine d’étincelles All
API Travaux Obtenir l’instruction Spark 200 Spark Session All
API Travaux Obtenez plusieurs déclarations Spark 200 Spark Session All
API Travaux Créer une session 2 Espace de travail EstUS, EstUS2, OuestUS, WestUS2, CentreUS, EstUS2EUAP, Europe de l’Ouest
API Travaux Créer une session 2 Espace de travail Toutes les autres régions
API Travaux Créer une tâche batch 2 Espace de travail All
API Travaux Obtenir un travail Spark Batch 200 Espace de travail All
API Travaux Obtenez un travail en plusieurs lots Spark 200 Espace de travail All

Note

La limite maximale de requêtes pour toutes les ressources et opérations est de 200 requêtes par seconde pour toutes les régions.

Tip

Si vous recevez un message d’erreur ou une réponse HTTP 429 qui dit

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)

ou

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’utilisateur doit utiliser la valeur de la période de temps fournie dans l’en-tête de réponse HTTP « Retry-After », pour attendre cet intervalle de temps lors des tentatives.Dans les scénarios à fort trafic, utiliser un intervalle de temps aléatoire, constant ou exponentiel pour les tentatives entraînerait toujours des défaillances HTTP 429 et entraînerait un grand nombre de tentatives, augmentant ainsi le temps total nécessaire pour que les requêtes soient acceptées par le service.

En utilisant plutôt le service fourni Retry-After valeur, les utilisateurs bénéficieraient d’un taux de réussite plus élevé dans les soumissions de tâches, car la valeur en secondes est calculée en fonction du trafic au moment donné afin d’optimiser le nombre de tentatives et le temps nécessaire pour que les requêtes clients soient acceptées par le serveur

Étapes suivantes

  • Last updated on