WLM 查詢監控規則 - Amazon Redshift

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

WLM 查詢監控規則

在 Amazon Redshift 工作負載管理 (WLM) 中,查詢監控規則會為 WLM 佇列定義以指標為基礎的效能邊界,並指定在查詢超出這些邊界時要採取的動作。例如,對於短期執行查詢專用的佇列,您可以建立規則,以將執行時間超過 60 秒的查詢取消。若要追蹤設計不良的查詢,您可以使用另一個規則來記錄含有巢狀迴圈的查詢。

請將查詢監控規則定義為工作負載管理 (WLM) 組態的一部分。每一個佇列最多可以定義 25 個規則,而全部佇列合計以 25 個規則為限制。每個規則最多包含三個條件 (或述詞) 和一個動作。述詞由指標、比較條件 (=、< 或 > ) 和值所組成。如果符合任何規則的所有述詞,就會觸發該規則的動作。可能的規則動作包括記錄、跳轉和中止,如下所述。

給定佇列中的規則僅套用至該佇列中執行的查詢。各規則彼此無關。

WLM 每 10 秒評估一次指標。如果同一時段內觸發多個規則,WLM 會啟動最嚴重的動作 — 中止、跳轉、記錄。如果動作是跳轉或中止,則會記錄動作,並從佇列中移出查詢。如果動作是記錄,則查詢會在佇列中繼續執行。WLM 會依每個規則,對每個查詢只啟動一個記錄動作。如果佇列包含其他規則,那些規則仍然有效。如果動作是跳轉,且將查詢路由至另一個佇列,則會套用新佇列的規則。

當符合規則的所有述詞時,WLM 會將一列寫入 STL_WLM_RULE_ACTION 系統資料表。此外,Amazon Redshift 會將目前執行中查詢的查詢指標記錄到STV_QUERY_METRICS。已完成之查詢的指標存放在 STL_QUERY_METRICS 中。

定義查詢監控規則

您可以將查詢監控規則定義為 WLM 組態的一部分,而 WLM 組態是您在叢集的參數群組定義中定義。

您可以使用AWS Management Console或以編程方式使用 JSON。

注意

如果您選擇以程式設計方式建立規則,強烈建議您使用主控台來產生 JSON,再加入參數群組定義中。如需詳細資訊,請參閱「」使用主控台建立或更新查詢監控規則使用 設定參數值AWS CLI中的Amazon Redshift 叢集管理指南

若要定義查詢監控規則,請指定下列元素:

  • 規則名稱 — 規則名稱在 WLM 組態內必須是唯一的。規則名稱最多為 32 個英數字元或底線,且不可含有空格和問號。每個佇列最多可以有 25 個規則,而全部佇列合計最多 25 規則。

  • 一或多個述詞 — 每個規則最多可以有三個述詞。如果符合任何規則的所有述詞,就會觸發相關聯的動作。述詞由指標名稱、運算子 ( =、< 或 > ) 和值所定義。例如,query_cpu_time > 100000。如需指標清單及各種指標的範例值,請參閱本節後續的查詢監控指標

  • 動作 — 如果觸發多個規則,WLM 會選擇具有最嚴重動作的規則。依嚴重性遞增順序,可能的動作如下:

    • 日誌 — 記錄 STL_WLM_RULE_ACTION 系統資料表中的查詢相關資訊。只需要寫入日誌記錄時,請使用「記錄」動作。WLM 依每個規則,對每個查詢最多只建立一個日誌。在記錄動作之後,其他規則仍然有效,且 WLM 會繼續監控查詢。

    • 跳轉 (僅適用於手動 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 秒,如下列 JSON 程式碼片段所示。

"rules": [ { "rule_name": "rule_query_execution", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 50 } ], "action": "abort" } ]

有關創建或修改查詢監視規則的步驟,請參閲使用主控台建立或更新查詢監控規則wlm_json_configuration 參數中的屬性中的Amazon Redshift 叢集管理指南

在下列主題中,您可以找到查詢監控規則的詳細資訊:

查詢監控指標

下表描述查詢監控規則中使用的指標。(這些指標不同於 STV_QUERY_METRICSSTL_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

查詢執行時間 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

巢狀迴圈聯結資料列數 nested_loop_join_row_count 巢狀迴圈聯結中的數字或資料列。

有效值為 0 到 999

傳回的資料列數 return_row_count 查詢傳回的資料列數。

有效值為 0 到 999

區段執行時間 segment_execution_time 單一區段經過的執行時間 (秒)。為了避免或減少取樣錯誤,請在規則中包含 segment_execution_time > 10

有效值為 0 到 86,388。

Spectrum 掃描的資料列數 spectrum_scan_row_count Amazon Amazon Redshift Spectrum 查詢在 Amazon S3 中掃描的資料列數。

有效值為 0 到 999

Spectrum 掃描大小 spectrum_scan_size_mb Amazon Redshift Spectrum 查詢在 Amazon S3 中掃描的資料大小 (以 MB 為單位)。

有效值為 0 到 999

查詢優先順序 query_priority 查詢的優先順序。

有效值為HIGHESTHIGHNORMALLOWLOWEST。使用大於 (>) 和小於 (<) 運算子比較 query_priority 時,HIGHEST 大於 HIGHHIGH 大於 NORMAL,以此類推。

注意
  • query_queue_time 述詞不支援跳轉動作。也就是說,會忽略定義為在符合 query_queue_time 述詞時進行跳轉的規則。

  • 區段執行時間太短可能會導致某些指標取樣錯誤,例如 io_skewquery_cpu_percent。為了避免或減少取樣錯誤,請在規則中包含區段執行時間。segment_execution_time > 10 是很理想的起點。

SVL_QUERY_METRICS 檢視顯示已完成之查詢的指標。SVL_QUERY_METRICS_SUMMARY 檢視顯示已完成之查詢的指標最大值。請使用這些檢視中的值來協助決定臨界值,以定義查詢監控規則。

查詢監控規則範本

使用 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 > 120io_skew > 1.30 當一個節點配量的 I/O 速率比其他配量高出許多時,就會發生 I/O 扭曲。以扭曲 1.30 (平均值的 1.3 倍) 為起點應該太高。I/O 扭曲偏高不一定是問題,但加上執行查詢時間太長時,就可能表示分佈樣式或排序索引鍵有問題。

查詢監控規則的系統資料表和檢視

當符合規則的所有述詞時,WLM 會將一列寫入 STL_WLM_RULE_ACTION 系統資料表。這一列包含觸發規則的查詢和所產生動作的詳細資訊。

此外,Amazon Redshift 會在下列系統資料表和檢視中記錄查詢指標。