Compartilhar via

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

  • Artigo

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 Simultaneously e Jobs 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

Próximas etapas