Limites de concurrence et de débit d’API pour les pools Apache Spark dans Azure Synapse Analytics

  • Article

Les sections suivantes répertorient différentes limites numériques pour les pools et LES API Spark pour gérer les travaux dans Azure Synapse Analytics.

Limites des ressources

Le tableau suivant montre les limites maximales des travaux 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 quelles que soient leurs tailles de nœud, vCore et configurations de mémoire, et s’appliquent à toutes les instances créées d’un pool Spark, quel que soit l’utilisateur, sauf indication contraire.

Ressource Métrique Limite Étendue Régions Notes
travaux Exécution simultanée 50 Pool Spark Tous La limite s’applique à tous les utilisateurs d’une définition de pool Spark. Par exemple, si deux utilisateurs envoient des travaux sur le même pool Spark, le nombre cumulé de travaux en cours d’exécution pour les deux utilisateurs ne peut pas dépasser 50.
travaux Mis en file d'attente. 200 Pool Spark Tous La limite s’applique à tous les utilisateurs d’une définition de pool Spark.
travaux Nombre maximal de travaux actifs 250 Pool Spark Tous La limite s’applique à tous les utilisateurs d’une définition de pool Spark.
travaux Nombre maximal de travaux actifs 1 000 Espace de travail Tous
Cœurs Limite de cœurs par utilisateur Basé sur la définition du pool Pool Spark Tous Par exemple, si un pool Spark est défini comme un pool à 50 cœurs, chaque utilisateur peut utiliser jusqu’à 50 cœurs dans le pool Spark spécifique, car chaque utilisateur obtient 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 Tous Par exemple, si un espace de travail a une limite de 200 cœurs, tous les utilisateurs de tous les pools de l’espace de travail ne peuvent pas utiliser plus de 200 cœurs combinés.
Livy Taille maximale de la charge utile pour la requête Livy 100 kots Livy Tous

Notes

  • Le nombre maximal de travaux actifs est le nombre total de travaux soumis, qui comprend à la fois Jobs Running Simultaneously et Jobs Queued, c’est-à-dire, Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Limites du taux de l’API

Le tableau suivant montre les limites de limitation pour les API de gestion de session et de travail Spark.

Ressource Métrique Limite (requêtes par seconde) Étendue Régions
API Jobs Obtenir une session Spark 200 Spark Session Tous
API Jobs Obtenir une session Spark 200 Pool Spark Tous
API Jobs Obtenir l’instruction Spark 200 Spark Session Tous
API Jobs Obtenir plusieurs instructions Spark 200 Spark Session Tous
API Jobs Créer une session 2 Espace de travail EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Europe Ouest
API Jobs Créer une session 2 Espace de travail Toutes les autres régions
API Jobs Créer un travail batch 2 Espace de travail Tous
API Jobs Obtenir un travail Spark Batch 200 Espace de travail Tous
API Jobs Obtenir plusieurs travaux Spark Batch 200 Espace de travail Tous

Notes

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

Conseil

Si vous obtenez un message d’erreur ou une réponse HTTP 429 qui lit

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 période fournie dans l’en-tête de réponse HTTP « Retry-After » pour attendre cet intervalle de temps lors de l’exécution de nouvelles tentatives.Dans les scénarios de trafic élevé, l’utilisation d’un intervalle de temps aléatoire, constant ou exponentiel pour les nouvelles tentatives entraînerait toujours des échecs HTTP 429 et entraînerait un nombre élevé de nouvelles tentatives en augmentant le temps total nécessaire pour que les demandes soient acceptées par le service.

Au lieu de cela, en utilisant le service fourni Retry-After valeur, les utilisateurs connaissent un taux de réussite plus élevé dans les soumissions de travaux, car la valeur en secondes est calculée en fonction du trafic à un point dans le temps pour optimiser le nombre de nouvelles tentatives et le temps nécessaire pour que les demandes du client soient acceptées par le serveur

Étapes suivantes