版本限制

• 內核版本為v6.6.1.0及以上的AnalyticDB PostgreSQL 6.0版實例，以及內核版本為v7.0.6.3及以上的AnalyticDB PostgreSQL 7.0版實例，可以通過控制臺直接將資源管理方式切換為資源組管理。

• 內核版本為v6.6.1.0以下的AnalyticDB PostgreSQL 6.0版實例，以及內核版本為v7.0.6.3以下的AnalyticDB PostgreSQL 7.0版實例需要提交工單來將資源管理方式切換為資源組管理。

如何查看實例內核版本，請參見查看內核小版本。

資源組（Resource Group）簡介

云原生數據倉庫 AnalyticDB PostgreSQL 版支持使用資源組（Resource Group）對數據庫進行資源管理，相對于使用資源隊列（Resource Queue）管理資源的方式具有更精細化、管理資源類別更全面的優勢。資源組管理與資源隊列管理不能同時使用，僅能使用一個，開啟資源組管理之后資源隊列自動失效。關于資源隊列的更多介紹，請參見使用Resource Queue（資源隊列）進行負載管理。

在使用資源組進行資源管理時，可以為資源組綁定一個或多個數據庫賬號，并針對每個資源組單獨設置其特定的CPU、內存和并發限制等，來管理各個資源組綁定賬號提交的查詢，但SET、RESET和SHOW命令不受資源組配置限制。

6.0資源組

AnalyticDB PostgreSQL 6.0版資源組支持配置的資源類別如下：

6.0資源組內存管理

數據庫按照各個資源組設置的memory_limit在各個資源組之間預留內存資源，如果各個資源組的memory_limit總和小于100，數據庫會將剩余未預留的內存分配給資源組全局共享內存池。數據庫以先到先得的方式為事務分配資源組全局共享內存。

每個資源組預留的內存池內部，資源組按照MEMORY_SHARED_QUOTA設定每個資源組內用于固定預留部分和共享部分的內存比例。如果MEMORY_SHARED_QUOTA參數設置為100%，那么資源組內部的所有內存都將被視為共享內存，所有任務都可以使用這塊內存；如果MEMORY_SHARED_QUOTA參數值小于100%，系統將根據設定的比例將內存劃分為固定部分和共享部分，固定部分是每個任務獨占的內存，而共享部分是所有任務共享的內存空間。AnalyticDB PostgreSQL 6.0版資源組內存管理機制詳解如下圖所示：

6.0資源組并發管理

• 當進入系統的查詢達到所屬資源組的并發數上限后，該資源組新進入的查詢需要進行等待。并發限制排隊時遵循先進先出的原則。

• 當提交的查詢由于達到并發限制而進行等待時，查看pg_stat_activity視圖時對應查詢處于waiting狀態，并且waiting_reason為group。

6.0資源組CPU管理

云原生數據倉庫 AnalyticDB PostgreSQL 版資源組支持管理各個組的CPU分配比例，是一種允許搶占的CPU管理方式，數據庫按照各個group設定的CPU_RATE_LIMIT值的比例進行CPU時間片分配。如果某資源組設置了較高的CPU_RATE_LIMIT值，那么在競爭CPU時，該資源組將獲得較多的CPU時間片，從而更多的執行任務，反之則限制其對CPU資源的使用。同時，資源管理功能支持CPU搶占，如果一個資源組在執行任務而其余資源組沒有任務時，那么這個資源組就會占有全部CPU資源。

• 在兩個資源組都很繁忙時，使用CPU_RATE_LIMIT為40創建的資源組將分配兩倍于使用CPU_RATE_LIMIT 為20創建的資源組的CPU資源。

• 在CPU_RATE_LIMIT為40的資源組無查詢進入時，CPU_RATE_LIMIT為20的資源組可以使用接近全部的CPU資源。

6.0落盤管理

云原生數據倉庫 AnalyticDB PostgreSQL 版源組支持對查詢的落盤閾值進行管理。在云原生數據倉庫 AnalyticDB PostgreSQL 版中內存密集型算子執行過程可能會產生大量中間臨時結果，會需要臨時溢出到磁盤，通過調整MEMORY_SPILL_RATIO來增加或減少溢出。因此只有需要產生大量中間臨時結果的操作類型受此控制。仍有很多操作是無法溢出到磁盤上的，這些操作會繼續占用內存，即使內存使用超過上限值，內存仍有可能增加。

• 當MEMORY_SPILL_RATIO大于0時，算子落盤閾值由MEMORY_SPILL_RATIO決定。當敏感事務內存達到此閾值，將被溢出到磁盤。

• 當MEMORY_SPILL_RATIO等于0時，算子落盤閾值由statement_mem決定。statement_mem的詳細信息，請參見性能參數調優。

當集群負載大、內存資源緊張時，調小所在資源組的memory_spill_ratio，讓內存密集型算子如hashagg、join、sort等在運算過程中更多地進行落盤運算，以減少內存使用。當集群負載小、內存資源充足時，調大所在資源組的memory_spill_ratio，讓落盤閾值提高，更多地在內存中進行計算，以提高查詢的執行效率。

7.0資源組

AnalyticDB PostgreSQL 7.0版資源組支持配置的資源類別如下：

7.0 資源組并發管理

• 當進入系統的查詢達到所屬資源組的并發數上限后，新進入該資源組的查詢需要進行等待。并發限制排隊時遵循先進先出的原則。

• 當提交的查詢由于達到并發限制而進行等待時，查看pg_stat_activity視圖時wait_event_type為ResourceGroup。

• 當所在group有大量查詢處于并發等待時，需要合理提高資源組并發能力，否則所在group的查詢性能可能受到影響。

7.0資源組內存管理

AnalyticDB PostgreSQL 7.0版資源組結合MEMORY_LIMIT配置，以及statement_mem、gp_resgroup_memory_query_fixed_mem參數來管理資源組的內存使用。

• 當gp_resgroup_memory_query_fixed_mem被配置為大于0的值后，單個查詢能夠使用的最大內存被限定為該值。

• 當gp_resgroup_memory_query_fixed_mem被配置為0（默認值）時，資源組結合statement_mem和MEMORY_LIMIT確定單個查詢能夠使用的內存值。具體如下：

  • 當所在資源組的MEMORY_LIMIT設置為-1時，資源組管理的單個查詢能夠使用的內存上限被限定為statement_mem。

  • 當所在資源組的MEMORY_LIMIT設置大于-1的值時，資源組管理的單個查詢能夠使用的內存上限被限定為max(memory_limit/concurrency, statement_mem)，即MEMORY_LIMIT除以并發值的結果，與statement_mem中的最大值。例如，在數據庫中有一個叫做etl的資源組，它的MEMORY_LIMIT設置成了2.0 GB，并發值設為5。所以默認情況下，單個查詢預計能夠使用的內存值為400 MB?？紤]如下場景：

• 用戶etl1提交了查詢Q1，并且session級別配置了gp_resgroup_memory_query_fixed_mem為800 MB（set gp_resgroup_memory_query_fixed_mem='800MB'），statement_mem設置為900MB，Q1最高能夠占用800MB的內存。

• 用戶etl2提交了查詢Q2，沒有配置session級別配置gp_resgroup_memory_query_fixed_mem參數，statement_mem設置為300 MB，小于400 MB，所以Q2提交到系統，并占用了400 MB的內存。

• 用戶etl3提交了查詢Q3，沒有配置session級別配置gp_resgroup_memory_query_fixed_mem參數，statement_mem設置為700 MB，大于400 MB，所以Q3提交到系統，并占用了700 MB的內存。

7.0資源組CPU管理

AnalyticDB PostgreSQL 7.0版資源組基于CPU_MAX_PERCENT管理每個資源組能夠使用的CPU使用率最大值，基于CPU_WEIGHT管理資源組在各個資源組之間的分配比例。會按照各個資源組的CPU_WEIGHT比例去分配CPU時間片，同時保證各個資源組的CPU使用率不超過設定的CPU_MAX_PERCENT值。

例如，數據庫中存在rg1和rg2兩個group，rg1的CPU_MAX_PERCENT設定為30，CPU_WEIGHT設定為100；rg2的CPU_MAX_PERCENT設定為60，CPU_WEIGHT設定為50。

1. 只有rg1中存在活躍查詢，rg2中不存在活躍查詢。此時rg1的CPU使用率會達到30%，rg2的CPU使用率會達到60%。

2. rg1和rg2中同時存在活躍查詢。此時數據庫會將CPU時間片按照100:50的優先級分配，直至某個資源組的CPU使用率達到了對應的CPU_MAX_PERCENT的限制值。例如，rg1的CPU使用率達到了30%，在此之后即使兩者的WEIGHT依然是100:50的關系，也會優先向rg2分配，以確保rg1的CPU使用率不超過30%。

開啟資源組管理

通過控制臺開啟或關閉資源組管理

內核版本為v6.6.1.0及以上的AnalyticDB PostgreSQL 6.0版實例，可以通過控制臺開啟或關閉資源組管理。切換資源管理模式由資源隊列變為資源組，切換過程中會重啟實例，并存在大約5分鐘實例不可用，請合理規劃時間，避免您的業務受到影響。具體操作，請參見如下步驟：

1. 登錄云原生數據倉庫AnalyticDB PostgreSQL版控制臺。
2. 在控制臺左上角，選擇實例所在地域。
3. 找到目標實例，單擊實例ID。

4. 在左側導航欄，單擊工作負載管理。

5. 單擊開啟資源組管理，并在彈窗中單擊確定。

通過提交工單開啟或關閉資源組管理

內核版本為v6.6.1.0以下的AnalyticDB PostgreSQL 6.0版實例和AnalyticDB PostgreSQL 7.0版實例，需要提交工單開啟或關閉資源組管理。

開啟資源組管理功能后，系統會自動創建一個default_group資源組。在監控與報警 > 實例監控頁面的資源組監控頁簽可以查看所有資源組監控信息，以及各個Segment的CPU和內存使用等。

新增資源組

開啟資源組管理后，您可以通過控制臺或后臺執行SQL的方式新增資源組。

CREATE RESOURCE GROUP <group_name> WITH (group_attribute=value [, ... ])

CPU_RATE_LIMIT=integer
MEMORY_LIMIT=integer
[ CONCURRENCY=integer ]
[ MEMORY_SHARED_QUOTA=integer ]
[ MEMORY_SPILL_RATIO=integer ]

CPU_MAX_PERCENT=integer
[CPU_WEIGHT=integer ]
[ CONCURRENCY=integer ]
[ MEMORY_LIMIT=integer ]
[ MIN_COST=integer ]

查看資源組配置

新增資源組后，您可以通過控制臺或后臺執行SQL的方式查看資源組配置。

SELECT * FROM gp_toolkit.gp_resgroup_config;

修改資源組配置

您可以通過控制臺或后臺執行SQL的方式修改資源組配置。

ALTER RESOURCE GROUP <group_name> 
SET CONCURRENCY|CPU_RATE_LIMIT|MEMORY_LIMIT|MEMORY_SHARED_QUOTA|MEMORY_SPILL_RATIO <value>;

ALTER RESOURCE GROUP <group_name> 
SET CPU_MAX_PERCENT|CPU_WEIGHT|CONCURRENCY|MEMORY_LIMIT|MIN_COST <value>;

綁定數據庫賬號

您可以通過控制臺或后臺執行SQL的方式為資源組綁定數據庫賬號。如何創建數據庫賬號，請參見創建數據庫賬號。

• 每個資源組可以綁定一個或多個數據庫賬號，但每個賬號只能綁定一個資源組。

• 數據初始賬號默認綁定default_group資源組。

• 沒有綁定資源組的數據庫賬號，會默認綁定default_group資源組。

刪除資源組

您可以通過控制臺或后臺執行SQL的方式刪除資源組。

DROP RESOURCE GROUP <group_name>;

手動查詢資源組監控信息

6.0版本

SELECT * FROM gp_toolkit.gp_resgroup_status;

以下是各個監控項的描述：

7.0版本

查詢排隊時間和排隊數

SELECT * FROM gp_toolkit.gp_resgroup_status;

以下是各個監控項的描述：

查詢CPU使用率和內存使用率

SELECT * FROM gp_toolkit.gp_resgroup_status_per_host;

以下是各個監控項的描述：

關閉資源組管理

如果您需要將資源管理模式切換為資源隊列，您可以通過控制臺關閉資源組管理。關閉過程中會重啟實例，并存在大約5分鐘實例不可用，請合理規劃時間，避免您的業務受到影響。具體操作如下：

1. 登錄云原生數據倉庫 AnalyticDB PostgreSQL版控制臺。

2. 在控制臺左上角，選擇實例所在的地域。

3. 找到目標實例，單擊實例ID。

4. 在左側導航欄，單擊工作負載管理，單擊關閉資源組管理。