本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
WLM 查詢監控規則
在 Amazon Redshift 工作負載管理 (WLM) 中,查詢監控規則會定義WLM佇列的指標型效能界限,並指定查詢超出這些界限時要採取的動作。例如,對於短期執行查詢專用的佇列,您可以建立規則,以將執行時間超過 60 秒的查詢取消。若要追蹤設計不良的查詢,您可以使用另一個規則來記錄含有巢狀迴圈的查詢。
您可以在工作負載管理 (WLM) 組態中定義查詢監控規則。每一個佇列最多可以定義 25 個規則,而全部佇列合計以 25 個規則為限制。每個規則最多包含三個條件 (或述詞) 和一個動作。述詞由指標、比較條件 (=、< 或 > ) 和值所組成。如果符合任何規則的所有述詞,就會觸發該規則的動作。可能的規則動作包括記錄、跳轉和中止,如下所述。
給定佇列中的規則僅套用至該佇列中執行的查詢。各規則彼此無關。
WLM 每 10 秒評估一次指標。如果在同一期間觸發多個規則, 會WLM選擇具有最嚴重動作的規則。如果兩個規則的動作具有相同的嚴重性, 會根據規則名稱依字母順序WLM執行規則。如果動作是跳轉或中止,則會記錄動作,並從佇列中移出查詢。如果動作是記錄,則查詢會在佇列中繼續執行。WLM 每個規則每個查詢僅啟動一個日誌動作。如果佇列包含其他規則,那些規則仍然有效。如果動作是跳轉,且將查詢路由至另一個佇列,則會套用新佇列的規則。如需針對特定查詢執行的查詢監控和追蹤動作的相關資訊,請參閱 短期查詢加速 中的範例集合。
符合所有規則的述詞時, 會將資料列WLM寫入STL_WLM_RULE_ACTION系統資料表。此外,Amazon Redshift 會將目前執行中查詢的查詢指標記錄到 STV_QUERY_METRICS。已完成之查詢的指標儲存在 STL_QUERY_METRICS 中。
定義查詢監控規則
您可以在WLM組態中建立查詢監控規則,而這些規則會定義成叢集參數群組定義的一部分。
您可以使用 建立規則, AWS Management Console 或使用 以程式設計方式建立規則JSON。
注意
如果您選擇以程式設計方式建立規則,強烈建議使用主控台來產生JSON您在參數群組定義中包含的 。如需詳細資訊,請參閱《Amazon Redshift 管理指南》中的使用主控台建立或修改查詢監控規則和使用 AWS CLI設定參數值。
若要定義查詢監控規則,請指定下列元素:
-
規則名稱 – 規則名稱在WLM組態中必須是唯一的。規則名稱最多為 32 個英數字元或底線,且不可含有空格和問號。每個佇列最多可以有 25 個規則,而全部佇列合計最多 25 規則。
-
一或多個述詞 – 每個規則最多可以有三個述詞。如果符合任何規則的所有述詞,就會觸發相關聯的動作。述詞由指標名稱、運算子 ( =、< 或 > ) 和值所定義。例如,
query_cpu_time > 100000
。如需指標清單及各種指標的範例值,請參閱本節後續的已佈建 Amazon Redshift 的查詢監控指標。 -
動作 – 如果觸發多個規則, 會WLM選擇具有最嚴重動作的規則。依嚴重性遞增順序,可能的動作如下:
-
日誌 – 在 STL_WLM_RULE_ACTION 系統資料表中記錄查詢的相關資訊。只需要寫入日誌記錄時,請使用「記錄」動作。WLM 每個規則最多會為每個查詢建立一個日誌。在日誌動作之後,其他規則仍然有效,WLM並繼續監控查詢。
-
Hop (僅適用於手動 WLM) – 記錄動作並將查詢跳至下一個相符佇列。如果沒有另一個相符的佇列,則會取消查詢。QMR 只跳 CREATE TABLE AS (CTAS) 陳述式和唯讀查詢,例如SELECT陳述式。如需詳細資訊,請參閱WLM 查詢佇列跳轉。
-
中止 – 記錄動作並終止查詢。QMR 不會停止COPY陳述式和維護操作,例如 ANALYZE和 VACUUM。
-
變更優先順序 (僅適用於自動 WLM) – 變更查詢的優先順序。
-
若要限制查詢的執行時間,建議您建立查詢監控規則,而不是使用WLM逾時。例如,您可以max_execution_time
設定為 50,000 毫秒,如下列JSON程式碼片段所示。
"max_execution_time": 50000
但是,我們建議您改為定義等效的查詢監控規則。下列範例示範將 query_execution_time
設為 50 秒的查詢監控規則:
"rules": [ { "rule_name": "rule_query_execution", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 50 } ], "action": "abort" } ]
如需建立或修改查詢監控規則的步驟,請參閱《Amazon Redshift 管理指南》中的使用主控台建立或修改查詢監控規則和 wlm_json_configuration 參數中的屬性。
在下列主題中,您可以找到查詢監控規則的詳細資訊:
已佈建 Amazon Redshift 的查詢監控指標
下表描述查詢監控規則中使用的指標。(這些指標不同於 STV_QUERY_METRICS 和 STL_QUERY_METRICS 系統資料表中儲存的指標。)
對於給定的指標,將會在查詢層級或區段層級追蹤效能臨界值。如需區段和步驟的相關資訊,請參閱查詢計劃和執行工作流程。
注意
WLM 逾時 參數不同於查詢監控規則。
指標 | 名稱 | 描述 |
---|---|---|
查詢CPU時間 |
query_cpu_time
|
CPU 查詢使用的時間,以秒為單位。 CPU time 與 不同Query execution time 。有效值為 0–999,999。 |
已讀取的區塊 |
query_blocks_read
|
查詢所讀取的 1 MB 資料區塊數。 有效值為 0–1,048,575。 |
掃描的資料列數 |
scan_row_count
|
掃描步驟的資料列數。資料列計數,指的是在篩選標記要刪除的資料列 (幽靈資料列) 之前,且在套用使用者定義的查詢篩選條件之前所發出的資料列總數。 有效值為 0–999,999,999,999,999。 |
查詢執行時間 |
query_execution_time
|
查詢經過的執行時間 (秒)。執行時間不包括在佇列中等待所花的時間。 有效值為 0–86,399。 |
查詢佇列時間 |
query_queue_time
|
在佇列中等待的時間 (秒)。 有效值為 0 至 86,399。 |
CPU 用量 |
query_cpu_usage_percent
|
查詢使用的CPU容量百分比。 有效值為 0–6,399。 |
記憶體到磁碟 |
query_temp_blocks_to_disk
|
用來寫入中間結果的暫時磁碟空間,以 1 MB 區塊為單位。 有效值為 0–319,815,679。 |
CPU 偏移 |
cpu_skew
|
任何層的最大CPU用量與所有層的平均CPU用量比率。此指標在區段層級中定義。 有效值為 0–99。 |
I/O 扭曲 |
io_skew
|
任何分割讀取區塊數上限 (I/O) 與所有分割平均讀取區塊數的比率。此指標在區段層級中定義。 有效值為 0–99。 |
已聯結的資料列 |
join_row_count
|
聯結步驟中處理的資料列數。 有效值為 0–999,999,999,999,999。 |
巢狀迴圈聯結資料列數 |
nested_loop_join_row_count
|
巢狀迴圈聯結中的數字或資料列。 有效值為 0–999,999,999,999,999。 |
傳回的資料列數 |
return_row_count
|
查詢傳回的資料列數。 有效值為 0–999,999,999,999,999。 |
區段執行時間 |
segment_execution_time
|
單一區段經過的執行時間 (秒)。為了避免或減少取樣錯誤,請在規則中包含 segment_execution_time
> 10 。有效值為 0–86,388。 |
Spectrum 掃描的資料列數 |
spectrum_scan_row_count
|
Amazon Redshift Spectrum 查詢在 Amazon S3 中掃描的資料列數。 有效值為 0–999,999,999,999,999。 |
Spectrum 掃描大小 |
spectrum_scan_size_mb
|
Amazon Redshift Spectrum 查詢在 Amazon S3 中掃描的資料大小 (以 MB 為單位)。 有效值為 0–999,999,999,999,999。 |
查詢優先順序 |
query_priority
|
查詢的優先順序。 有效值為 |
注意
query_queue_time
述詞不支援跳轉動作。也就是說,會忽略定義為在符合query_queue_time
述詞時進行跳轉的規則。-
區段執行時間太短可能會導致某些指標取樣錯誤,例如
io_skew
和query_cpu_usage_percent
。為了避免或減少取樣錯誤,請在規則中包含區段執行時間。segment_execution_time > 10
是很理想的起點。
SVL_QUERY_METRICS 檢視顯示已完成之查詢的指標。SVL_QUERY_METRICS_SUMMARY 檢視顯示已完成之查詢的指標最大值。請使用這些檢視中的值來協助決定臨界值,以定義查詢監控規則。
Amazon Redshift Serverless 的查詢監控指標
下表描述 Amazon Redshift Serverless 查詢監控規則中使用的指標。
指標 | 名稱 | 描述 |
---|---|---|
查詢CPU時間 | max_query_cpu_time |
CPU 查詢使用的時間,以秒為單位。 CPU time 與 不同Query execution time 。有效值為 0–999,999。 |
已讀取的區塊 |
max_query_blocks_read
|
查詢所讀取的 1 MB 資料區塊數。 有效值為 0–1,048,575。 |
掃描的資料列數 |
max_scan_row_count
|
掃描步驟的資料列數。資料列計數,指的是在篩選標記要刪除的資料列 (幽靈資料列) 之前,且在套用使用者定義的查詢篩選條件之前所發出的資料列總數。 有效值為 0–999,999,999,999,999。 |
查詢執行時間 | max_query_execution_time |
查詢經過的執行時間 (秒)。執行時間不包括在佇列中等待所花的時間。如果查詢超過設定的執行時間,Amazon Redshift Serverless 會停止查詢。 有效值為 0–86,399。 |
查詢佇列時間 | max_query_queue_time |
在佇列中等待的時間 (秒)。 有效值為 0 至 86,399。 |
CPU 用量 |
max_query_cpu_usage_percent
|
查詢使用的CPU容量百分比。 有效值為 0–6,399。 |
記憶體到磁碟 |
max_query_temp_blocks_to_disk
|
用來寫入中間結果的暫時磁碟空間,以 1 MB 區塊為單位。 有效值為 0–319,815,679。 |
已聯結的資料列 |
max_join_row_count
|
聯結步驟中處理的資料列數。 有效值為 0–999,999,999,999,999。 |
巢狀迴圈聯結資料列數 |
max_nested_loop_join_row_count
|
巢狀迴圈聯結中的數字或資料列。 有效值為 0–999,999,999,999,999。 |
注意
max_query_queue_time
述詞不支援跳轉動作。也就是說,會忽略定義為在符合max_query_queue_time
述詞時進行跳轉的規則。-
區段執行時間太短可能會導致某些指標取樣錯誤,例如
max_io_skew
和max_query_cpu_usage_percent
。
查詢監控規則範本
當您使用 Amazon Redshift 主控台新增規則時,您可以選擇從預先定義的範本建立規則。Amazon Redshift 會建立包含一組述詞的新規則,並以預設值填入述詞。預設動作為記錄。您可以修改述詞和動作,以符合您的使用案例。
下表列出可用的範本。
範本名稱 | 述詞 | 描述 |
---|---|---|
巢狀迴路聯結 |
nested_loop_join_row_count > 100
|
巢狀迴圈聯結可能表示聯結述詞不完整,通常會產生非常大的傳回集 (笛卡兒乘積)。請使用較小的資料列數,以儘早發現潛在的失控查詢。 |
查詢傳回的大量的資料列數 |
return_row_count > 1000000
|
如果您將佇列專用於簡單、短期執行的查詢,您可以包含規則來找出傳回較多資料列數的查詢。範本以 1 百萬個資料列為預設值。對於某些系統,您可能認為 1 百萬個資料列太多,或在較大的系統中,十億或更多個資料列可能太多。 |
一同加入大量的資料列數 |
join_row_count > 1000000000
|
涉及非常多資料列的聯結步驟可能表示需要更嚴格的篩選條件。範本以十億個資料列為預設值。對於用於快速、簡單查詢的臨機操作 (一次性) 佇列,您可以使用較小的數目。 |
寫入中繼結果時出現高磁碟用量 |
query_temp_blocks_to_disk > 100000
|
目前執行查詢時,查詢執行引擎會將中繼結果寫入磁碟 (溢出的記憶體)RAM。這種情況通常是惡意查詢所引起,這通常也是使用最多磁碟空間的查詢。可接受的磁碟用量臨界值根據叢集節點類型和節點數而有所不同。範本以 100,000 個區塊或 100 GB 為預設值。對於小型叢集,您可以使用較小的數目。 |
查詢執行時間長且 I/O 高度扭曲 | segment_execution_time > 120 和 io_skew > 1.30 |
當一個節點配量的 I/O 速率比其他配量高出許多時,就會發生 I/O 扭曲。以扭曲 1.30 (平均值的 1.3 倍) 為起點應該太高。I/O 扭曲偏高不一定是問題,但加上執行查詢時間太長時,就可能表示分佈樣式或排序索引鍵有問題。 |
查詢監控規則的系統資料表和檢視
符合所有規則的述詞時, 會將資料列WLM寫入STL_WLM_RULE_ACTION系統資料表。這一列包含觸發規則的查詢和所產生動作的詳細資訊。
此外,Amazon Redshift 會在下列系統資料表和檢視中記錄查詢指標。
-
STV_QUERY_METRICS 資料表會顯示目前執行之查詢的指標。
-
STL_QUERY_METRICS 資料表會記錄以完成之查詢的指標。
-
SVL_QUERY_METRICS 檢視顯示已完成之查詢的指標。
-
SVL_QUERY_METRICS_SUMMARY 檢視顯示已完成之查詢的指標最大值。