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

As seções a seguir listam vários limites numéricos para pools e APIs Spark para gerenciar vagas no Azure Synapse Analytics.

Limites de recursos

A tabela a seguir 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 nós, vCore e configurações de memória e se aplicam a todas as instâncias criadas de um Spark Pool, independentemente do usuário, salvo indicação em contrário.

Recurso Métrica Limit Scope Regions Observações
Jobs Funcionando simultaneamente 50 Piscina Spark All O limite se aplica a todos os usuários da definição de Spark Pool. Por exemplo, se dois usuários estiverem submetendo trabalhos contra o mesmo Spark Pool, então o número acumulado de trabalhos rodando para os dois usuários não pode exceder 50.
Jobs Em fila 200 Piscina Spark All O limite se aplica a todos os usuários da definição de Spark Pool.
Jobs Empregos Máximos Ativos 250 Piscina Spark All O limite se aplica a todos os usuários da definição de Spark Pool.
Jobs Empregos Máximos Ativos 1000 Workspace All
Núcleos Limite de Núcleos por Usuário Com base na definição do pool Piscina Spark All Por exemplo, se um pool Spark for definido como um pool de 50 núcleos, cada usuário pode usar até 50 núcleos dentro do pool específico do Spark, já que cada usuário recebe sua própria instância do pool.
Núcleos Limite de Núcleos para Todos os Usuários Baseado na definição do espaço de trabalho Workspace All Por exemplo, se um espaço de trabalho tem um limite de 200 núcleos, então todos os usuários 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 solicitação Livy 100kBytes Livy All

Note

  • O Número Máximo de Vagas Ativas é o número total de vagas enviadas, que inclui tanto Jobs Running Simultaneously quanto Jobs Queued, ou seja, Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Limitações de requisições da API

A tabela a seguir mostra os limites de limitação para as APIs de gerenciamento de trabalhos e sessões do Spark.

Recurso Métrica Limite (Consultas por Segundo) Scope Regions
API de Trabalhos Obter sessão do Spark 200 Sessão Spark All
API de Trabalhos Obter sessão do Spark 200 Piscina Spark All
API de Trabalhos Obter instrução Spark 200 Sessão Spark All
API de Trabalhos Obtenha Múltiplas Declarações Spark 200 Sessão Spark All
API de Trabalhos Criar Sessão 2 Workspace Leste dos EUA, LesteUS2, Oeste dos EUA, Oeste dos EUA, CentroEUA, 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 All
API de Trabalhos Obter trabalho em lote do Spark 200 Workspace All
API de Trabalhos Conseguir um Emprego em Vários Lotes de Faíscas 200 Workspace All

Note

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 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 esperar 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 ainda resultaria em falhas no HTTP 429 e geraria um grande número de tentativas, aumentando assim o tempo total para que as solicitações fossem aceitas pelo serviço.

Em vez disso, ao usar o serviço fornecido Retry-After valor, os usuários experimentariam uma taxa de sucesso maior nas submissões de trabalhos, já que o valor em segundos é calculado com base no tráfego em um momento para otimizar o número de tentativas e o tempo necessário para que as solicitações do cliente sejam aceitas pelo servidor

Próximas Etapas 

  • Last updated on