Concurrency and API rate limits for Apache Spark pools in Azure Synapse Analytics

В следующих разделах перечислены различные числовые ограничения для пулов и API Spark для управления задачами в Azure Synapse Analytics.

Ограничения ресурсов

В следующей таблице показаны максимальные лимиты заданий и ядер для отдельных рабочих пространств и пулов Spark.

Important

Ограничения, указанные для пулов Spark, зависят от размера узлов, vCore и конфигураций памяти и применяются ко всем созданным экземплярам пула Spark независимо от пользователя, если не указано иное.

Resource Metric Limit Объем Регионы Примечания.
Jobs Запуск одновременно 50 Spark Pool All Ограничение применяется для всех пользователей определения Spark Pool. Например, если два пользователя отправляют задания в одном и том же Spark Pool, то общее количество запущенных заданий для этих двух пользователей не может превышать 50.
Jobs В очереди 200 Spark Pool All Ограничение применяется для всех пользователей определения Spark Pool.
Jobs Максимальное количество активных вакансий 250 Spark Pool All Ограничение применяется для всех пользователей определения Spark Pool.
Jobs Максимальное количество активных вакансий 1000 Workspace All
Cores Лимит по ядрам на пользователя На основе определения пула Spark Pool All Например, если пул Spark определен как пул из 50 ядер, каждый пользователь может использовать до 50 ядер внутри конкретного пула Spark, поскольку у каждого пользователя есть свой собственный экземпляр пула.
Cores Ограничение ядер для всех пользователей На основе определения рабочего пространства Workspace All Например, если рабочее пространство ограничено 200 ядер, то все пользователи во всех пулах рабочего пространства не могут использовать более 200 ядер вместе взятые.
Ливий Максимальный размер полезной нагрузки для запроса Ливия 100 кБайт Ливий All

Note

  • Максимальное количество активных вакансий — это общее количество поданных вакансий, включающее и Jobs Running SimultaneouslyJobs Queued, то есть , то есть Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Ограничения скорости API

В следующей таблице показаны пределы троттлинга для API управления искрой и сессий.

Resource Metric Лимит (количество запросов в секунду) Объем Регионы
API заданий Получение сеанса Spark 200 Сеанс Spark All
API заданий Получение сеанса Spark 200 Spark Pool All
API заданий Получение инструкции Spark 200 Сеанс Spark All
API заданий Получите несколько заявлений о искры 200 Сеанс Spark All
API заданий Создание сеанса 2 Workspace EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Западная Европа
API заданий Создание сеанса 2 Workspace Все остальные регионы
API заданий Создать пакетную работу 2 Workspace All
API заданий Получение пакетного задания Spark 200 Workspace All
API заданий Получите работу с несколькими Spark Batch 200 Workspace All

Note

Максимальный лимит запросов для всех ресурсов и операций — 200 запросов в секунду для всех регионов.

Tip

Если вы получаете сообщение об ошибке или HTTP-429 ответ, который гласит

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)

Или

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)

Пользователю следует использовать значение временного периода, указанное в заголовке ответа HTTP «Retry-After», чтобы дождаться этого интервала при повторных попытках.В случаях с высоким трафиком использование случайного, постоянного или экспоненциального временного интервала для повторных попыток всё равно приведёт к сбоям HTTP 429 и большому числу повторных попыток, что увеличивает общее время, необходимое для принятия запросов сервисом.

Вместо этого, используя предоставляемый сервис Retry-After ценность, пользователи получали бы более высокий процент успеха при подаче заданий, поскольку значение вычисляется за секунды на основе трафика за момент времени для оптимизации количества повторных попыток и времени, необходимого для принятия запросов клиента сервером

Дальнейшие действия

  • Last updated on