要求速率限制原則
工作負載群組的要求速率限制原則可讓您限制分類為工作負載群組、每個工作負載群組或每個主體的並行要求數目。
速率限制會在工作負載群組的要求速率限制強制原則所定義的層級上強制執行。
原則物件
要求速率限制原則具有下列屬性:
名稱 | 支援的值 | 描述 |
---|---|---|
IsEnabled | true , false |
指出是否已啟用原則。 |
範圍 | WorkloadGroup , Principal |
套用限制的範圍。 |
LimitKind | ConcurrentRequests , ResourceUtilization |
要求速率限制的種類。 |
屬性 | 屬性包 | 要求速率限制的屬性。 |
並行要求速率限制
種類 ConcurrentRequests
的要求速率限制包含下列屬性:
名稱 | 類型 | 描述 | 支援的值 |
---|---|---|---|
MaxConcurrentRequests | int |
並行要求的最大數目。 | [0 , 10000 ] |
注意
- 如果工作負載群組沒有並行要求上限的指定限制,則會受限於的預設最大值
10000
。
當要求超過並行要求的最大數目限制時:
- 要求的狀態 (如系統資訊命令所表示) 將會是
Throttled
。 - 錯誤訊息會包含節流的來源,以及已超過的容量。
下表顯示一些並行要求範例,這些要求超過上限,以及這些要求傳回的錯誤訊息:
案例 | 錯誤訊息 |
---|---|
已分類至default 工作負載群組的節流.create table 命令,在工作負載群組的範圍內有80個並行要求的限制。 |
管理命令因為節流而中止。 在一些輪詢後重試可能會成功。 CommandType: 'TableCreate', Capacity: 80, Origin: 'RequestRateLimitPolicy/WorkloadGroup/default'。 |
分類為名為 MyWorkloadGroup 的工作負載群組的節流查詢,此群組在工作負載群組的範圍內有 50 個並行要求的限制。 |
查詢因為節流而中止。 在一些輪詢後重試可能會成功。 容量:50,原始來源:'RequestRateLimitPolicy/WorkloadGroup/MyWorkloadGroup'。 |
已分類為名為 MyWorkloadGroup 的工作負載群組的節流查詢,其限製為主體範圍內的10個並行要求。 |
查詢因為節流而中止。 在一些輪詢後重試可能會成功。 容量:10,原始來源:'RequestRateLimitPolicy/WorkloadGroup/MyWorkloadGroup/Principal/aaduser=9e04c4f5-1abd-48d4-a3d2-9f58615b4724;6ccf3fe8-6343-4be5-96c3-29a128dd9570'。 |
- HTTP 回應碼會是
429
。 子代碼會是TooManyRequests
。 - 例外狀況類型將會
QueryThrottledException
用於查詢,以及ControlCommandThrottledException
用於管理命令。
資源使用率速率限制
種類 ResourceUtilization
的要求速率限制包含下列屬性:
名稱 | 類型 | 描述 | 支援的值 |
---|---|---|---|
ResourceKind | ResourceKind |
要限制的資源。 當 為 TotalCpuSeconds 時ResourceKind ,會根據已完成要求的CPU使用率後續執行報告來強制執行限制。 不會計算報告 CPU 使用率為 0.005 秒或較低的要求。 限制 () MaxUtilization 代表要求在指定時間範圍內耗用的總 CPU 秒數 (TimeWindow ) 。 例如,執行臨機操作查詢的使用者每小時可能會有1000個CPU秒的限制。 如果超過此限制,即使同時啟動,後續查詢仍會受到節流,因為累計 CPU 秒已超過滑動時段內定義的限制。 |
RequestCount , TotalCpuSeconds |
MaxUtilization | long |
可使用的資源最大值。 | RequestCount: [1 , 16777215 ]; TotalCpuSeconds: [1 , 828000 ] |
TimeWindow | timespan |
套用限制的滑動時間範圍。 | [00:01:00 , 1.00:00:00 ] |
當要求超過資源使用率的限制時:
- 要求的狀態 (如系統資訊命令所表示) 將會是
Throttled
。 - 錯誤訊息將包含節流 的來源 和超過的 配額 。 例如:
下表顯示一些超過資源使用率限制的要求範例,以及這些要求傳回的錯誤訊息:
案例 | 錯誤訊息 |
---|---|
分類為名為 Automated Requests 的工作負載群組的節流要求,此群組在主體範圍內每小時有 1000 個要求的限制。 |
要求因為超過配額限制而遭到拒絕。 資源: 'RequestCount', 配額: '1000', TimeWindow: '01:00:00', Origin: 'RequestRateLimitPolicy/WorkloadGroup/Automate Requests/Principal/aadapp=9e04c4f5-1abd-48d4-a3d2-9f58615b4724;6ccf3fe8-6343-4be5-96c3-29a128dd9570'。 |
節流要求,分類為名為 Automated Requests 的工作負載群組,其限製為工作負載群組範圍每小時 2000 個 CPU 秒總數。 |
要求因為超過配額限制而遭到拒絕。 資源:'TotalCpuSeconds'、配額:'2000'、TimeWindow:'01:00:00'、Origin:'RequestRateLimitPolicy/WorkloadGroup/自動化要求'。 |
- HTTP 回應碼會是
429
。 子代碼會是TooManyRequests
。 - 例外狀況類型會是
QuotaExceededException
。
一致性如何影響速率限制
使用強式一致性時,並行要求上限的預設限制取決於叢集的SKU,並計算為: Cores-Per-Node x 10
。 例如,使用 Azure D14_v2 節點設定的叢集,其中每個節點都有 16 個虛擬核心,將會有 x 10
= 160
的預設限制。16
使用弱式一致性時,最大並行要求的有效預設限制取決於叢集的SKU和查詢標頭數目,並計算為: Cores-Per-Node x 10 x Number-Of-Query-Heads
。 例如,使用 Azure D14_v2和 5 個查詢前端設定的叢集,其中每個節點都有 16 個虛擬核心,將會有 x x800
10
= 5
的有效預設限制。16
如需詳細資訊,請參閱 查詢一致性。
default
工作負載群組
default
工作負載群組預設會定義下列原則。 您可以改變此原則。
[
{
"IsEnabled": true,
"Scope": "WorkloadGroup",
"LimitKind": "ConcurrentRequests",
"Properties": {
"MaxConcurrentRequests": < Cores-Per-Node x 10 >
}
}
]
注意
- 當您變更工作負載群組的原則
default
時,必須針對並行要求上限定義限制。
範例
下列原則允許最多:
- 工作負載群組的 500 個並行要求。
- 每個主體 25 個並行要求。
- 每小時每個主體 50 個要求。
[
{
"IsEnabled": true,
"Scope": "WorkloadGroup",
"LimitKind": "ConcurrentRequests",
"Properties": {
"MaxConcurrentRequests": 500
}
},
{
"IsEnabled": true,
"Scope": "Principal",
"LimitKind": "ConcurrentRequests",
"Properties": {
"MaxConcurrentRequests": 25
}
},
{
"IsEnabled": true,
"Scope": "Principal",
"LimitKind": "ResourceUtilization",
"Properties": {
"ResourceKind": "RequestCount",
"MaxUtilization": 50,
"TimeWindow": "01:00:00"
}
}
]
下列原則會封鎖分類至工作負載群組的所有要求:
[
{
"IsEnabled": true,
"Scope": "WorkloadGroup",
"LimitKind": "ConcurrentRequests",
"Properties": {
"MaxConcurrentRequests": 0
}
},
]
相關內容
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應