Limites de simultaneidade e taxa de API para pools do Apache Spark no Azure Synapse Analytics
As seções a seguir listam vários limites numéricos para pools e APIs do Spark para gerenciar trabalhos no Azure Synapse Analytics.
Limites de recursos
A tabela a seguir mostra os limites máximos de trabalhos e núcleos para workspaces individuais e pools do Spark.
Importante
Os limites especificados para os pools do Spark são independentemente de seus tamanhos de nó, vCore e configurações de memória e se aplicam a todas as instâncias criadas de um Pool do Spark, independentemente do usuário, a menos que indicado de outra forma.
| Recurso | Métrica | Limite | Escopo | Regiões | Observações |
|---|---|---|---|---|---|
| Trabalhos | Execução simultânea | 50 | Pool do Spark | Todos | O limite se aplica a todos os usuários de uma definição do Pool do Spark. Por exemplo, se dois usuários estiverem enviando trabalhos no mesmo Pool do Spark, o número cumulativo de trabalhos em execução para os dois usuários não poderá exceder 50. |
| Trabalhos | Em fila | 200 | Pool do Spark | Todos | O limite se aplica a todos os usuários de uma definição do Pool do Spark. |
| Trabalhos | Máximo de trabalhos ativos | 250 | Pool do Spark | Todos | O limite se aplica a todos os usuários de uma definição do Pool do Spark. |
| Trabalhos | Máximo de trabalhos ativos | 1000 | Workspace | Todos | |
| Núcleos | Limite de núcleos por usuário | Com base na definição do pool | Pool do Spark | Todos | Por exemplo, se um pool do Spark for definido como um pool de 50 núcleos, cada usuário poderá usar até 50 núcleos no pool específico do Spark, já que cada usuário obtém sua própria instância do pool. |
| Núcleos | Limite de núcleos entre todos os usuários | Com base na definição do workspace | Workspace | Todos | Por exemplo, se um workspace tiver um limite de 200 núcleos, todos os usuários em todos os pools dentro do workspace não poderão usar mais de 200 núcleos combinados. |
| Livy | Tamanho máximo do conteúdo para a solicitação livy | 100kBytes | Livy | Tudo |
Observação
- Máximo de Trabalhos Ativos é o número total de trabalhos enviados, que inclui
Jobs Running SimultaneouslyeJobs Queued, ou seja,Max Active Jobs = Jobs Running Simultaneously + Jobs Queued
Limites de taxa da API
A tabela a seguir mostra os limites de limitação para as APIs de gerenciamento de sessão e trabalho do Spark.
| Recurso | Métrica | Limite (Consultas por Segundo) | Escopo | Regiões |
|---|---|---|---|---|
| API de trabalhos | Obter sessão do Spark | 200 | Sessão do Spark | Todos |
| API de trabalhos | Obter sessão do Spark | 200 | Pool do Spark | Todos |
| API de trabalhos | Obter instrução Spark | 200 | Sessão do Spark | Todos |
| API de trabalhos | Obter várias instruções spark | 200 | Sessão do Spark | Todos |
| API de trabalhos | Criar Sessão | 2 | Workspace | EastUS, EastUS2, WestUs, WestUS2, CentralUs, EastUS2EUAP, Europa Ocidental |
| API de trabalhos | Criar Sessão | 2 | Workspace | Todas as outras regiões |
| API de trabalhos | Criar Trabalho em Lote | 2 | Workspace | Todos |
| API de trabalhos | Obter Trabalho em Lote do Spark | 200 | Workspace | Todos |
| API de trabalhos | Obter vários trabalhos em lotes do Spark | 200 | Workspace | Todos |
Observação
O limite máximo de solicitações para todos os recursos e operações é de 200 consultas por segundo para todas as regiões.
Dica
Se você receber uma mensagem de erro ou uma resposta HTTP 429 que lê
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)
O usuário deve usar o valor do período de tempo fornecido no cabeçalho de resposta HTTP "Retry-After", para aguardar esse intervalo de tempo ao executar novas tentativas.Em cenários de alto tráfego, o uso de um intervalo de tempo aleatório, constante ou exponencial para as novas tentativas ainda resultaria em falhas HTTP 429 e incorreria em um alto número de repetições, aumentando o tempo geral gasto para que as solicitações fossem aceitas pelo serviço.
Em vez disso, usando o serviço fornecido Retry-After valor, os usuários experimentariam uma taxa de sucesso maior em envios de trabalho, pois o valor em segundos é calculado com base no tráfego pontual para otimizar o número de repetições e o tempo necessário para que as solicitações do cliente sejam aceitas pelo servidor