理論+示例，詳解GaussDB(DWS)資源管理

摘要：合理地管理和分配系統資源，是保證資料庫系統穩定高效運行的關鍵。本文分享自華為雲社區《GaussDB(DWS)資源管理能力介紹與應用示例》，作者：門前一棵葡萄樹。一、資源管理能力 1.1 概述資料庫運行過程中使用的公共資源包含：系統資源（CPU、記憶體、網路等）和資料庫共用資源(鎖、計數 ...

摘要：合理地管理和分配系統資源，是保證資料庫系統穩定高效運行的關鍵。

本文分享自華為雲社區《GaussDB(DWS)資源管理能力介紹與應用示例》，作者：門前一棵葡萄樹。

一、資源管理能力

1.1 概述

資料庫運行過程中使用的公共資源包含：系統資源（CPU、記憶體、網路等）和資料庫共用資源(鎖、計數等)。作業運行過程中總是希望獲得更多的公共資源，以獲得最好的執行性能。但是公共資源的濫用可能導致資料庫系統的不穩定，引發資源過載，影響高優業務的QoS（服務質量），甚至阻塞業務運行。因此，合理地管理和分配系統資源，是保證資料庫系統穩定高效運行的關鍵。

資源管理的目標：

防止資源過載，引發系統級故障；
實現高優業務的優先調度，保證高優業務QoS；
實現業務之間的資源隔離，防止業務之間資源爭搶嚴重；
實現業務的錯峰分時調度，防止瞬時高併發影響系統穩定性；
快速識別異常查詢，保證正常業務穩定運行。

1.2 基本原理

資源池是一種用於對系統資源進行劃分的技術，通過為資源池設置資源上限的方式，實現對其內運行作業的資源管控。資源池可以幫助系統管理員更好地管理和分配系統資源，提高系統的可用性和穩定性。

GaussDB(DWS)提供了資源管理功能，藉助資源池實現業務之間的資源隔離和查詢調度（不同業務路由至不同資源池）。GaussDB(DWS)支持兩種路由策略：

用戶-資源池：將用戶關聯至資源池，用戶執行作業時，根據“用戶-資源池”的關聯關係，將作業路由至對應資源池執行。
query_band負載識別：業務設置query_band（USERSET參數），根據query_band和資源池關聯關係，將作業路由至對應資源池執行。

實際應用過程中，建議優先使用用戶-資源池的路由方式；在用戶-資源池的路由方式無法滿足隔離訴求時，使用query_band負載識別實現業務隔離。

1.3 能力介紹

GaussDB(DWS)支持負載管理、資源管控、異常規則、查詢過濾器以及負載計劃等資源管理能力，不同的資源管理能力有不同的使用場景，實際應用中可能會用到其中1~N個資源管理能力。

1.3.1 負載管理

支持基於併發和估算記憶體的查詢調度，防止併發過大引發資源爭搶嚴重、導致查詢堆積。多CN場景下，CN之間互相不感知負載情況，因此無法精確控制整個集群的併發和記憶體使用，可能觸發記憶體不足報錯。因此為保證多CN場景下的併發和記憶體可控，設計實現CCN用於查詢的統一調度。CM在第一次集群啟動時，通過集群部署形式，選擇編號最小的CN作為CCN，CCN故障之後，由CM選擇新的CCN進行替換。

雖然CCN管控可以實現更為精準的管控，但是CCN管控邏輯更為複雜且涉及CN-CCN間通信，通信延遲（10ms~1s之間）和複雜的管控邏輯可能導致作業性能不穩定，此外CCN還可能成為提高系統併發的瓶頸。因此設計實現“短查詢加速”功能，實現對簡單查詢和複雜查詢的分別管控。複雜查詢執行時間長、記憶體消耗大，CCN管控對其性能影響有限；簡單查詢執行時間短、記憶體消耗小，CN管控可以降低管控對其的性能影響。CCN管控的主要目的是防止記憶體不足報錯，因此我們根據估算記憶體對查詢進行分類：

簡單查詢：估算記憶體小於32MB；
複雜查詢：估算記憶體大於等於32MB。

為提升簡單查詢性能，預設情況下簡單查詢只進行併發控制，而不進行記憶體和CPU管控。實際應用場景下，優先順序低的業務可能性能不敏感，而且需要精準管控其使用的CPU和記憶體資源，此時簡單查詢也需要進行資源管控。為適應更多的使用場景，短查詢加速功能支持開啟和關閉：

開啟短查詢加速：簡單查詢在CN進行管控，複雜查詢在CCN管控；
關閉短查詢加速：不區分簡單查詢和複雜查詢，所有查詢均在CCN進行管控。

為了便於區分，我們將CN管控稱為快車道，CCN管控稱為慢車道。快車道只在CN上進行併發控制，不支持記憶體和CPU管控；慢車道在CCN上進行併發和記憶體控制，同時支持CPU管控。其中，快車道併發對應資源池max_dop參數，慢車道併發對應資源池active_statements參數，慢車道記憶體對應資源池mem_percent參數。

1.3.2 CPU資源管控

GaussDB(DWS)基於cgroups實現了兩種CPU管控能力：基於cpu.shares的共用配額管控和基於cpuset的專屬限額管控。

專屬限額限制資源池內作業可以使用的CPU核，隔離更為徹底，用於防止低優作業占用過多CPU，影響高優作業性能。

共用配額僅在CPU繁忙時生效，不同資源池之間按照配額比例輪詢占用CPU，不同業務之間存在CPU爭搶，可能影響業務性能。

1.3.3 網路管控（821以上版本支持）

GaussDB(DWS)支持基於SP+DWRR演算法的網路調度與基於令牌桶的網路流控，實現資源池之間按比例的網路調度的同時，實現了網路欠佳SQL的降級與流控。

1.3.4 空間管控（非本文重點）

空間管控主要有兩層目的：一是防止磁碟滿，一是對業務使用磁碟空間進行限制。GaussDB(DWS)支持以下空間管控能力：

資料庫只讀：CM每10分鐘檢測一次數據盤使用率，使用率超過閾值時，設置資料庫只讀；使用率低於閾值時，解除資料庫只讀。資料庫只讀情況下，只允許只讀作業執行。資料庫只讀後，通過讀寫事務內執行DROP/TRUNCATE清理磁碟空間： " START TRANSACTION READ WRITE;DROP/TRUNCATE TABLE;COMMIT; "。

用戶空間管控：限制用戶在單個CN/DN上可以使用的空間上限，根據表的屬主（owner）進行管控，而不管執行插入的用戶是誰。相關語法：CREATE ALTER USER xxx PERM SPACE ‘xxx G/M/K’。

Schema空間管控：提供Schema級別的單實例空間管控能力，相關語法：CREATE/ALTER SCHEMA xxx WITH PERM SPACE 'xx G/M/K'。

1.3.5 異常規則

異常規則用於預防單個作業占用資源過多、執行時間過長，防止單個作業長時間大量占用資源，導致系統整體吞吐下降、影響其他作業性能。GaussDB(DWS)支持以下異常規則：

1.3.6 查詢過濾器

GaussDB(DWS)查詢過濾器提供查詢過濾功能，對加入黑名單的作業進行過濾，禁止執行。主要應用場景包含以下兩種：

異常熔斷機制：配置異常規則後，作業頻繁觸發異常規則，對於觸發異常規則次數達到閾值的查詢自動加入黑名單進行過濾。
緊急攔截：作業引發CORE、hang或性能大幅下降等問題時，需要緊急規避時，可以將作業加入黑名單進行過濾。

1.3.7 資源管理計劃

用戶在不同時間需要重點保障的業務可能不一樣，每個業務所需的併發和資源在不同時間段也可能不相同，因此用戶在不同時間所需的資源管理配置可能就有所不同。資源管理計劃支持在指定時間自動切換資源管理配置，用戶可按需創建多個資源管理計劃。創建資源管理計劃、配置計劃生效時間並啟動計劃後，GaussDB(DWS)將在計劃生效時間自動切換資源配置。

1.4 能力邊界（註意點）

首先，需要明確的一點是資源管理不是萬能的，並不是所有的資源類問題資源管理都能解決，大部分資源不足類問題資源管理基本都解決不了。其次需要清楚資源管理有兩個主要目的：其一是為了避免資源的無序使用，從而防止系統級故障的發生，同時避免查詢堆積的情況出現；其二是為了實現業務之間的資源隔離，防止不同業務之間因為資源爭搶而導致高優業務性能下降，從而影響高優業務的QoS。明確了以上幾點，我們再來看資源管理能幹什麼、不能幹什麼，可能就更好理解了：

資源管理可以對業務併發進行限制，實現流量削峰。但是限制併發也就意味著吞吐量的下降，如果業務併發持續走高，限制併發可能導致業務運行不完，不限制併發又會影響其他業務，此時可能就需要考慮其他方法提升業務性能（擴容/升配/SQL優化）。
資源管理並不能提升系統整體吞吐量，相反，資源隔離很有可能降低系統整體吞吐。例如：應用資源管理前，CPU持續飆高在90%以上，查詢堆積嚴重，業務運行不完。這種情況下對低優業務進行CPU限額隔離後，很有可能可以大幅降低CPU使用率；但是相應的低優業務可能大面積報錯或無法完成。
資源管理可以實現資源隔離與管控，但是相較於無背景壓力，隔離管控後業務性能可能還是有所損耗。例如：有些用戶只對低優業務進行了CPU限額管控，而沒有對高優業務進行CPU管控。此時高優業務和低優業務很可能使用相同CPU，此時CPU使用率可能不到100%、甚至不足90% 。但是相對無背景壓力，同一時刻請求同一CPU的線程會更多，因此CPU調度時延也就越大。想要完成隔離CPU對性能的影響，需要對兩個業務都進行CPU限額管控，但是進行限額管控後，相對無背景壓力使用所有CPU性能可能也是有所下降的，此處不再展開。
資源管理並不能提升作業性能。有些用戶業務併發大、資源需求高，但是系統資源卻很少。業務串列可能都難以正常運行結束，此時想通過資源管理保障業務正常運行，基本是不可行的，最好的辦法還是擴容/升配/SQL優化。

二、應用示例

2.1 確認業務場景

資源管理的目的是對業務進行隔離管控，因此設計資源管理方案前，首先需要確認用戶業務場景：業務分類、業務優先順序、業務類型、業務併發情況、業務執行時間段以及業務高峰時間段。

確認業務分類，才能確定應該劃分幾個資源池；
確認業務優先順序，才能確定應該給哪個資源池多預留資源和併發；
確認業務併發和業務類型，才能確定是否需要進行併發控制和異常規則；
確認業務執行時間段，才能確認是否需要使用資源管理計劃；
確認業務高峰時間段，才能確認預留多少資源和併發合適。

為了避免過多的資源池對整體吞吐率產生負面影響，同時為了簡化資源管理方案，建議將資源池數量控制在5個以下，最好是3個及以下。如果業務分類較少（3個及以下），可以為每個業務分類創建一個資源池，以便更好地進行分類管理。如果業務分類較多，可以將優先順序相同的業務歸為同一類，並使用同一個資源池來管理。

業務優先順序一般分為以下幾類：

性能敏感的高優業務：該類業務一般執行時間短、業務併發不大，對性能非常敏感，一般不接受性能抖動；
無時效性要求的低優業務：該類業務對執行性能沒有要求，一般只要能出結果就行，包括但不限於：外圍應用查詢、自助分析業務等；
其他有一定性能要求的業務：該類業務普遍併發較大、執行時間較長，對性能有一定要求，但是可以有性能抖動，比如：標準報告、實時入庫等。

2.2 明確管控訴求

確認業務場景後，下一步就需要和用戶明確管控訴求。第一步確認業務場景後，其實已經可以形成初步資源管理方案，比如：應該創建幾個資源池、限制低優業務併發和資源使用（限額）、是否使用資源管理計劃等。

示例：

業務場景：用戶業務包含：入庫、查詢和外部接入。其中入庫和查詢使用同一用戶(user1)，外部接入使用一個用戶(user2)；入庫優先順序略低於查詢且入庫不能影響查詢性能，外部接入優先順序很低、接受報錯和長時間不出結果；入庫併發較大、消耗CPU較高。

對於以上業務場景，有以下基本訴求和初步資源管理方案：

有三類業務且優先順序各不相同，且各業務間有隔離管控訴求，因此需要創建3個資源池；
所有業務全部使用自建資源池，資源池進行併發控制，因此單CN併發上限（max_active_statements）可以設置一個較大值（建議300/500）；
外部接入優先順序低，因此考慮外部接入併發設置小一些，CPU核分配少一些，同時考慮到對其進行嚴格的CPU管控，因此關閉短查詢加速；
入庫和查詢使用同一用戶，因此需要用到query_band負載識別，用於區分入庫和查詢業務；
入庫優先順序略低於查詢且入庫不能大幅影響查詢性能，因此考慮對入庫和查詢均進行CPU限額管控，同時關閉短查詢加速；
查詢估算記憶體可能存在偏差，當估算過大時可能導致異常排隊，因此建議設置查詢估算記憶體上限。

初步資源管理方案資源池配置如下：

單CN併發上限：max_active_statements = 300/500 ??

其中，參數值後有“??”的表示參數大小為初步預估，需要與用戶溝通確認參數最終大小。

形成初步資源管理方案後，與用戶針對資源管理方案進行討論，確認管控訴求：

資源池：確認資源池數量是否合適，業務與資源池對應關係是否合適（可能存在多個業務對應一個資源池的情況）；
併發控制：各業務是否需要併發控制，併發上限是否合適；（資源管理上線前併發上限較難預估，一般前期會給一個比較大的值，後續上線後根據實際運行效果調整）
記憶體管控：業務是否需要記憶體管控，記憶體大小設置是否合理；（記憶體資源充足、業務間記憶體爭取不嚴重的場景下不需要記憶體管控；記憶體設置過小，記憶體管控可能導致不必要的排隊，影響系統吞吐）
查詢估算記憶體限制：可以通過TopSQL歷史記錄中作業估算記憶體和實際使用記憶體判斷是否合理；（估算記憶體上限設置過小可能影響作業性能，設置過大可能因為估算偏差導致異常排隊，需要綜合業務性能和記憶體使用情況考慮）
CPU管控：通過資源管理上線前，CPU使用率情況確認是否存在CPU瓶頸，同時確認後續是否有新業務上線；（存在CPU瓶頸或者後續可能上限大批新業務情況下建議提前配置好CPU管控，預防業務上線後大幅影響高優業務性能）
資源管理計劃：業務高峰時間段不同的情況下，可能需要用到資源管理計劃，在不同時間段重點保障不同業務；
其他管控訴求：確認用戶是否有其他管控訴求，比如：設置異常規則，防止查詢堆積和資源爭搶嚴重（雖然進行了資源隔離，但是爛SQL可能影響本業務內其他作業）。

以上只是列舉了常見的管控訴求討論點，實際應用中可以多發散。

三、配置資源管理

以上一章節中資源管理方案為例，說明如何配置資源管理方案。

3.1 配置資源池

如下圖所示，以respool_select資源池為例，按照用戶指南添加資源池中步驟添加資源池。名稱填寫“respool_select”；CPU資源選擇專屬限額，限額50%；記憶體資源限額50%；查詢併發（特指慢車道併發）上限100。填寫完成後點擊確認，完成資源池添加。資源池操作說明詳見：添加資源池、修改資源池、刪除資源池。

添加資源池完成後，顯示下圖所示界面。剛剛配置完成的參數在資源配置標簽內顯示；短查詢加速預設開啟且不限制簡單語句併發上限；中間位置顯示資源池關聯的異常規則，預設情況下關聯有兩個預設異常規則：單DN平均消耗CPU占比不超過50%，單DN運算元下盤不超過數據盤的1/10，超過限制後作業報錯退出；最下方顯示資源池關聯的用戶，點擊關聯用戶按鈕將“查詢用戶”關聯至該資源池。同理創建另外兩個資源池，並將“外部接入用戶”關聯至respool_other資源池。

註：對於需要設置自定義異常規則的資源池，在下方異常規則標簽欄點擊編輯即可配置異常規則。

3.2 短查詢加速配置

在資源池下拉列表中選擇剛剛添加的資源池respool_select，點擊短查詢配置右上方的編輯，修改簡單語句併發為150，修改完成後點擊保存。

對於另外兩個資源池，需要關閉短查詢加速，在資源池下拉列表中選擇對應資源池後，點擊短查詢配置中“短查詢加速”開關，關閉短查詢加速。

3.3 查詢估算記憶體設置

查詢估算記憶體上限暫時還不支持在界面配置，可以通過DAS執行SQL直接修改：

3.4 配置query_band

1. 修改用戶入庫業務，入庫業務會話內設置query_band：SET query_band='Jobname=upsert';--執行業務;--作業執行完重置query_band：reset query_band;示例：

postgres=> SET query_band='Jobname=copy_upsert';
SET
postgres=> INSERT INTO t1 SELECT generate_series(1,10000);
INSERT 0 10000
postgres=> RESET query_band;
RESET

2. 配置query_band，將入庫業務路由至資源池respool_upsert運行：

postgres=# SELECT * FROM gs_wlm_set_queryband_action('Jobname=copy_upsert', 'respool=respool_upsert');
 gs_wlm_set_queryband_action
-----------------------------
 t
(1 row)

3. 查詢pg_queryband_action視圖，確認query_band配置成功：

postgres=# select * from pg_queryband_action;
 qband | respool_id |    respool     | priority | qborder
---------------------+------------+----------------+----------+---------
 Jobname=copy_upsert | 2147483648 | respool_upsert | medium   | -1
(1 row)

4. 運行入庫作業過程中，查詢TopSQL實時視圖，確認query_band是否生效

postgres=# SELECT username, query_band, resource_pool, substr(query, 1, 30) FROM pgxc_wlm_session_statistics WHERE query_band IS NOT NULL;
 username | query_band | resource_pool | substr
----------+---------------------+----------------+--------------------------------
 user_elk | Jobname=copy_upsert | respool_upsert | INSERT INTO t1 SELECT generate
(1 row)

3.5 其他配置

1. 需要使用資源管理計劃的，可以參考資源管理計劃操作配置資源管理計劃。

2. GaussDB(DWS) 8.2.1及以上版本支持網路資源管控，假設三個資源池網路帶寬權重配比為respool_select:respool_upsert:respool_other = 5:4:1，使用DAS執行以下SQL配置網路管控：

ALTER RESOURCE POOL respool_select WITH(WEIGHT=5);
ALTER RESOURCE POOL respool_upsert WITH(WEIGHT=4);
ALTER RESOURCE POOL respool_other WITH(WEIGHT=1);

配置示例參見下圖：

假設外部接入業務運行超過20min，且網路帶寬占用超過128MB降級：

CREATE EXCEPT RULE bandwidth_rule1 WITH(bandwidth=128, ELAPSEDTIME=1200, action='penalty'); -- 創建異常規則
ALTER RESOURCE POOL respool_other WITH(EXCEPT_RULE='bandwidth_rule1'); -- 將異常規則關聯至資源池respool_other