Limites de concurrence et de débit d’API pour les pools Apache Spark dans Azure Synapse Analytics
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 SimultaneouslyetJobs 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