理論+示例，詳解GaussDB(DWS)資源管理-有解無憂

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

本文分享自華為云社區《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