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 Simultaneously
和Jobs 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值,使用者會在作業提交中遇到較高的成功率,因為以秒為單位的值是根據時間點流量來計算,以優化用戶端要求接受的重試次數和時間