WLM查詢監視規則 - Amazon Redshift
定義查詢監控規則已佈建 Amazon Redshift 的查詢監控指標Amazon Redshift Serverless 的查詢監控指標查詢監控規則範本查詢監控規則的系統資料表和檢視

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

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態的一部分，將其定義為叢集參數群組定義的一部分。

您可以使用 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繼續監視查詢。

    • 躍點 (僅適用於手動WLM) — 記錄動作並將查詢跳至下一個相符佇列。如果沒有另一個相符的佇列，則會取消查詢。QMR只跳躍 CREATETABLEAS (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"
    }            
]

如需建立或修改查詢監控規則的步驟，請參閱《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 查詢的優先順序。

有效值為HIGHEST、HIGH、NORMAL、LOW、LOWEST。使用大於 (>) 和小於 (<) 運算子比較 query_priority 時，HIGHEST 大於 HIGH、HIGH 大於 NORMAL，以此類推。
注意

  • 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 會在下列系統資料表和檢視中記錄查詢指標。