Limites de concorrência e taxa API para pools Apache Spark no Azure Synapse Analytics

As secções seguintes listam vários limites numéricos para pools Spark e APIs para gerir empregos no Azure Synapse Analytics.

Limites de recursos

A tabela seguinte mostra os limites máximos de trabalhos e núcleos para espaços de trabalho individuais e pools Spark.

Importante

Os limites especificados para os pools Spark são independentemente do tamanho dos seus nós, vCore e configurações de memória e aplicam-se a todas as instâncias criadas de um Spark Pool, independentemente do utilizador, salvo indicação em contrário.

Resource Métrica Limit Scope Regions Notes
Jobs A Correr Simultaneamente 50 Piscina Spark Todos O limite aplica-se a todos os utilizadores da definição de Spark Pool. Por exemplo, se dois utilizadores estiverem a submeter trabalhos contra o mesmo Spark Pool, então o número acumulado de trabalhos em execução para os dois utilizadores não pode exceder 50.
Jobs Em fila 200 Piscina Spark Todos O limite aplica-se a todos os utilizadores da definição de Spark Pool.
Jobs Empregos Máximos Ativos 250 Piscina Spark Todos O limite aplica-se a todos os utilizadores da definição de Spark Pool.
Jobs Empregos Máximos Ativos 1000 Espaço de trabalho Todos
Cores Limite de núcleos por utilizador Com base na definição do grupo Piscina Spark Todos Por exemplo, se um pool Spark for definido como um pool de 50 núcleos, cada utilizador pode usar até 50 núcleos dentro do pool específico do Spark, uma vez que cada utilizador recebe a sua própria instância do pool.
Cores Limite de Núcleos para Todos os Utilizadores Com base na definição do espaço de trabalho Espaço de trabalho Todos Por exemplo, se um espaço de trabalho tiver um limite de 200 núcleos, então todos os utilizadores de todos os pools dentro do espaço de trabalho não podem usar mais de 200 núcleos juntos.
Livy Tamanho máximo da carga útil para pedido Livy 100kBytes Livy Todos

Note

  • O número máximo de empregos ativos é o número total de empregos submetidos, que inclui tanto Jobs Running Simultaneously como Jobs Queued, ou seja, Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Limitações de taxa da API

A tabela seguinte mostra os limites de limitação para as APIs de gestão de trabalhos do spark e de sessões.

Resource Métrica Limite (Consultas por Segundo) Scope Regions
API de Trabalhos Obter sessão do Spark 200 Sessão Spark Todos
API de Trabalhos Obter sessão do Spark 200 Piscina Spark Todos
API de Trabalhos Obter declaração do Spark 200 Sessão Spark Todos
API de Trabalhos Obtenha Múltiplas Declarações Spark 200 Sessão Spark Todos
API de Trabalhos Criar Sessão 2 Espaço de trabalho EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Europa Ocidental
API de Trabalhos Criar Sessão 2 Espaço de trabalho Todas as outras regiões
API de Trabalhos Criar Trabalho em Lote 2 Espaço de trabalho Todos
API de Trabalhos Obter trabalho em lote do Spark 200 Espaço de trabalho Todos
API de Trabalhos Arranja Trabalho em Vários Lotes Spark 200 Espaço de trabalho Todos

Note

O limite máximo de pedidos para todos os recursos e operações é de 200 consultas por segundo para todas as regiões.

Dica

Se receber uma mensagem de erro ou uma resposta HTTP 429 que diga

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 utilizador deve usar o valor do período de tempo fornecido no cabeçalho de resposta HTTP "Retry-After", para esperar por esse intervalo de tempo ao realizar tentativas.Em cenários de alto tráfego, usar um intervalo de tempo aleatório, constante ou exponencial para as tentativas continuaria a resultar em falhas HTTP 429 e resultaria num grande número de tentativas, aumentando assim o tempo total necessário para que os pedidos fossem aceites pelo serviço.

Em vez disso, ao usar o serviço fornecido Retry-After valor, os utilizadores experienciariam uma taxa de sucesso mais elevada nas submissões de tarefas, pois o valor em segundos é calculado com base no tráfego no momento para otimizar o número de tentativas e o tempo necessário para que os pedidos do cliente sejam aceites pelo servidor

Passos seguintes

  • Last updated on