共用方式為


Azure Synapse Analytics 中 Apache Spark 集區的並行和 API 速率限制

下列各節列出 Spark 集區和 API 的各種數值限制,以管理 Azure Synapse Analytics 中的作業。

資源限制

下表顯示個別工作區和 Spark 集區作業和核心的最大限制。

重要

針對 Spark 集區指定的限制,不論其節點大小、虛擬核心和記憶體組態為何,並套用至 Spark 集區的所有已建立實例,除非另有注明。

資源 計量 限制 影響範圍 區域 附註
工作 同時執行 50 Spark 集區 全部 Spark 集區定義的所有使用者都適用限制。 例如,如果兩位使用者針對相同的 Spark 集區提交作業,則兩個使用者執行的累計作業數目不能超過 50。
工作 已排入佇列 200 Spark 集區 全部 Spark 集區定義的所有使用者都適用限制。
工作 作用中作業上限 250 Spark 集區 全部 Spark 集區定義的所有使用者都適用限制。
工作 作用中作業上限 1000 工作區 全部
核心 每位使用者的核心限制 根據集區定義 Spark 集區 全部 例如,如果 Spark 集區定義為 50 核心集區,則每個使用者可以在特定 Spark 集區內使用最多 50 個核心,因為每個使用者都會取得集區自己的實例。
核心 所有使用者的核心限制 根據工作區定義 工作區 全部 例如,如果工作區有 200 個核心的限制,則工作區內所有集區中的所有使用者都無法使用超過 200 個組合的核心。
Livy Livy 要求的承載大小上限 100kBytes Livy 全部

注意

  • [作用中作業上限] 是提交的作業總數,包括 Jobs Running SimultaneouslyJobs Queued ,亦即 Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

API 速率限制

下表顯示 Spark 作業和會話管理 API 的節流限制。

資源 計量 限制每秒 (查詢數) 範圍 區域
作業 API 取得 Spark 會話 200 Spark 會話 全部
作業 API 取得 Spark 會話 200 Spark 集區 全部
作業 API 取得 Spark 語句 200 Spark 會話 全部
作業 API 取得多個 Spark 語句 200 Spark 會話 全部
作業 API 建立會話 2 工作區 EastUS、EastUS2、WestUS、WestUS2、CentralUS、EastUS2EUAP、西歐
作業 API 建立會話 2 工作區 所有其他區域
作業 API 建立 Batch 作業 2 工作區 全部
作業 API 取得 Spark Batch 作業 200 工作區 全部
作業 API 取得多個 Spark Batch 作業 200 工作區 全部

注意

所有資源和作業的要求上限是所有區域的每秒 200 個查詢。

提示

如果您收到讀取的錯誤訊息或 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)

Or

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)

使用者應該使用「Retry-After」 HTTP 回應標頭中所提供的時間週期值,在執行重試時等候該時間間隔。在高流量案例中,針對重試使用隨機、常數或指數時間間隔仍會導致 HTTP 429 失敗,而且會導致大量重試,藉由增加服務接受要求的整體時間。

相反地,使用所提供的服務Retry-After值,使用者會在作業提交中遇到較高的成功率,因為以秒為單位的值是根據時間點流量來計算,以優化用戶端要求接受的重試次數和時間

下一步