Partilhar via


Limites de simultaneidade e taxa de API para conjuntos do Apache Spark no Azure Synapse Analytics

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

Limites de recursos

A tabela seguinte mostra os limites máximos de trabalhos e núcleos para áreas de trabalho individuais e conjuntos do Spark.

Importante

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

Recurso Metric Limite Âmbito Regiões Notas
Tarefas Em execução em simultâneo 50 Conjunto do Spark Todos O limite aplica-se a todos os utilizadores de uma definição de Conjunto do Spark. Por exemplo, se dois utilizadores estiverem a submeter tarefas no mesmo Conjunto do Spark, o número cumulativo de tarefas em execução para os dois utilizadores não pode exceder 50.
Tarefas Em fila 200 Conjunto do Spark Todos O limite aplica-se a todos os utilizadores de uma definição de Conjunto do Spark.
Tarefas Máximo de Tarefas Ativas 250 Conjunto do Spark Todos O limite aplica-se a todos os utilizadores de uma definição de Conjunto do Spark.
Tarefas Máximo de Tarefas Ativas 1000 Área de trabalho Todos
Núcleos Limite de Núcleos Por Utilizador Com base na Definição do Conjunto Conjunto do Spark Todos Por exemplo, se um conjunto do Spark for definido como um conjunto de 50 núcleos, cada utilizador pode utilizar até 50 núcleos no conjunto específico do Spark, uma vez que cada utilizador obtém a sua própria instância do conjunto.
Núcleos Limite de Núcleos em Todos os Utilizadores Com base na Definição da Área de Trabalho Área de trabalho Todos Por exemplo, se uma área de trabalho tiver um limite de 200 núcleos, todos os utilizadores em todos os conjuntos dentro da área de trabalho não poderão utilizar mais de 200 núcleos combinados.
Livy Tamanho máximo do Payload para o pedido livy 100kBytes Livy Todos

Nota

  • O Número Máximo de Tarefas Ativas é o número total de tarefas submetidas, que inclui e Jobs Running SimultaneouslyJobs Queued, ou seja, Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Limites de taxa de API

A tabela seguinte mostra os limites de limitação das APIs de gestão de sessões e tarefas do Spark.

Recurso Metric Limite (Consultas por Segundo) Âmbito 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 Conjunto do Spark Todos
API de Trabalhos Obter Declaração do Spark 200 Sessão do Spark Todos
API de Trabalhos Obter Múltiplas Instruções do Spark 200 Sessão do Spark Todos
API de Trabalhos Criar Sessão 2 Área de trabalho EUA Leste, E.U.A. Leste2, E.U.A. Oeste, E.U.A. Oeste2, EUA Central, LESTEUS2EUAP, Europa Ocidental
API de Trabalhos Criar Sessão 2 Área de trabalho Todas as outras regiões
API de Trabalhos Criar Tarefa do Batch 2 Área de trabalho Todos
API de Trabalhos Obter Tarefa do Apache Spark Batch 200 Área de trabalho Todos
API de Trabalhos Obter Várias Tarefas do Apache Spark Batch 200 Área de trabalho Todos

Nota

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 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 utilizador deve utilizar o valor do período de tempo fornecido no cabeçalho de resposta HTTP "Repetir Após", para aguardar por esse intervalo de tempo ao executar as repetições.Em cenários de tráfego elevado, a utilização de um intervalo de tempo aleatório, constante ou exponencial para as repetições ainda resultaria em falhas de HTTP 429 e incorreria num elevado número de repetições, aumentando o tempo global necessário para que os pedidos fossem aceites pelo serviço.

Em vez disso, ao utilizar o serviço fornecido Retry-After valor, os utilizadores teriam uma taxa de êxito mais elevada nas submissões de tarefas, uma vez que o valor em segundos é calculado com base no tráfego para um ponto anterior no tempo para otimizar o número de repetições e o tempo necessário para que os pedidos do cliente sejam aceites pelo servidor

Passos seguintes