簡(jiǎn)介：作者：阿里云數(shù)據(jù)庫(kù)OLAP產(chǎn)品部 - 子華

一 背景

AnalyticDB PostgreSQL版（簡(jiǎn)稱ADB PG）是阿里云數(shù)據(jù)庫(kù)團(tuán)隊(duì)基于PostgreSQL內(nèi)核（簡(jiǎn)稱PG）打造的一款云原生數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品。在數(shù)據(jù)實(shí)時(shí)交互式分析、HTAP、ETL、BI報(bào)表生成等業(yè)務(wù)場(chǎng)景，ADB PG都有著獨(dú)特的技術(shù)優(yōu)勢(shì)，在金融、物流、泛互聯(lián)網(wǎng)等行業(yè)都有廣泛的應(yīng)用，是傳統(tǒng)數(shù)倉(cāng)上云、去O去T、替換自建Greenplum的標(biāo)桿云上數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品。

數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品是數(shù)據(jù)分析系統(tǒng)的重要組件之一，各類線上業(yè)務(wù)對(duì)數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品的穩(wěn)定性、可用性具有很高的要求。缺乏有效的資源管理機(jī)制會(huì)導(dǎo)致數(shù)據(jù)庫(kù)產(chǎn)品的穩(wěn)定性下降，發(fā)生例如連接數(shù)打滿OS限制、內(nèi)存不足、進(jìn)程卡死等問題，從而影響產(chǎn)品的可用性。

Resource Queue（資源隊(duì)列）是ADB PG的一種資源管理方式，能夠?qū)?shù)據(jù)庫(kù)的CPU、內(nèi)存等資源進(jìn)行限制，對(duì)多租戶資源限制、保障數(shù)據(jù)庫(kù)穩(wěn)定運(yùn)行具有一定的作用。顧名思義，Resource Queue以隊(duì)列形式對(duì)運(yùn)行在數(shù)據(jù)庫(kù)集群上的SQL進(jìn)行資源管理。對(duì)于每個(gè)用戶，他的所有連接只能歸屬于一個(gè)隊(duì)列。而對(duì)于每個(gè)隊(duì)列能夠管理多個(gè)用戶的連接。沒有顯示指定資源隊(duì)列的用戶，會(huì)歸屬于默認(rèn)資源隊(duì)列管理。通過限制每個(gè)隊(duì)列的資源總量，我們可以達(dá)到限制某類業(yè)務(wù)或者某個(gè)用戶使用的資源總量的目的。

我們以ADB PG某在線交易平臺(tái)類客戶A為例，介紹Resource Queue的使用。客戶A基于ADB PG構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，日常運(yùn)行三類業(yè)務(wù)：以交易數(shù)據(jù)入庫(kù)為代表的實(shí)時(shí)類業(yè)務(wù)；用于支撐決策分析的報(bào)表類業(yè)務(wù)；以及用于實(shí)時(shí)大屏展示的可視化類業(yè)務(wù)。我們根據(jù)三類業(yè)務(wù)的不同特點(diǎn)，按如下策略配置資源隊(duì)列。

客戶A的實(shí)時(shí)類業(yè)務(wù)的典型代表是，交易數(shù)據(jù)經(jīng)Kafka->Flink->ADB PG鏈路實(shí)時(shí)寫入ADB PG。這類業(yè)務(wù)的典型特點(diǎn)是，峰值并發(fā)比較大，單個(gè)SQL資源消耗小。在進(jìn)行資源隊(duì)列限制前，業(yè)務(wù)高峰期經(jīng)常發(fā)生突然提高的并發(fā)查詢打滿數(shù)據(jù)庫(kù)連接，造成高可用探活查詢執(zhí)行失敗，引發(fā)實(shí)例不可用。對(duì)于這類業(yè)務(wù)我們將其關(guān)聯(lián)到一個(gè)高CPU權(quán)重、大并發(fā)限制（安全閾值內(nèi)）、單個(gè)SQL內(nèi)存份額低的隊(duì)列。既保證數(shù)據(jù)的快速入庫(kù)，又防止流量洪峰造成系統(tǒng)不穩(wěn)定。

客戶A的另一類典型業(yè)務(wù)是報(bào)表類、ETL類業(yè)務(wù)，這類業(yè)務(wù)會(huì)在實(shí)時(shí)類業(yè)務(wù)的低峰期進(jìn)行調(diào)度，生成報(bào)表以提供決策支持。這類業(yè)務(wù)涉及的數(shù)據(jù)量較大，消耗內(nèi)存量和產(chǎn)生的臨時(shí)文件量大。對(duì)于這類業(yè)務(wù)，我們將其關(guān)聯(lián)到低CPU權(quán)重、低并發(fā)限制，但是內(nèi)存份額高的隊(duì)列，在滿足業(yè)務(wù)需要的同時(shí)，控制內(nèi)存使用上限；

除此之外，客戶還基于ADB PG數(shù)據(jù)倉(cāng)庫(kù)支持?jǐn)?shù)據(jù)的實(shí)時(shí)可視化展示，這類可視化方案往往具有非常穩(wěn)定的并發(fā)，但是對(duì)查詢的延時(shí)具有一定的要求。對(duì)于這類業(yè)務(wù)，我們將其資源隊(duì)列設(shè)定為高CPU權(quán)重，低并發(fā)限制，以及寬泛的優(yōu)化器查詢計(jì)劃消耗份額，最大程度為其生成良好的查詢計(jì)劃，以保證業(yè)務(wù)穩(wěn)定。

接下來(lái)，本文會(huì)具體介紹Resource Queue的使用方式、狀態(tài)監(jiān)控，以及它的實(shí)現(xiàn)機(jī)制。

二 Resource Queue簡(jiǎn)介

Resource Queue支持通過SQL配置，支持進(jìn)行四種類型的資源限制：并發(fā)限制、CPU限制、內(nèi)存限制和查詢計(jì)劃限制。用戶可以通過SQL在數(shù)據(jù)庫(kù)內(nèi)定義多個(gè)資源隊(duì)列，并設(shè)置每個(gè)資源隊(duì)列的資源限制。在一個(gè)數(shù)據(jù)庫(kù)中，每個(gè)資源隊(duì)列可以關(guān)聯(lián)一個(gè)或多個(gè)數(shù)據(jù)庫(kù)用戶，而每個(gè)數(shù)據(jù)庫(kù)用戶只能歸屬于單個(gè)資源隊(duì)列。

另外，并不是所有提交到資源隊(duì)列的SQL都會(huì)受到隊(duì)列限制的限制，數(shù)據(jù)庫(kù)只會(huì)限制SELECT、SELECT INTO、CREATE TABLE AS SELECT、DECLARE CURSOR、INSERT、UPDATE 和DELETE這些類型SQL的資源利用。另外，在執(zhí)行EXPLAIN ANALYZE命令期跑的SQL也會(huì)被資源隊(duì)列排除。

資源隊(duì)列支持的資源限制配置如下：

配置名	配置說(shuō)明
MEMORY_LIMIT	隊(duì)列中所有查詢所使用的內(nèi)存總量。
ACTIVE_STATEMENTS	隊(duì)列中允許同時(shí)運(yùn)行的查詢數(shù)。超出該設(shè)置值的查詢需要排隊(duì)等待執(zhí)行。
PRIORITY	隊(duì)列的CPU使用優(yōu)先級(jí)，可以設(shè)置為以下級(jí)別：LOW、MEDIUM、HIGH 和MAX。默認(rèn)值為MEDIUM，優(yōu)先級(jí)越高的隊(duì)列會(huì)被分配越高的CPU份額。
MAX_COST	查詢計(jì)劃消耗限制。

通過SQL語(yǔ)句定義一個(gè)新的資源隊(duì)列：

CREATE RESOURCE QUEUE etl WITH (ACTIVE_STATEMENTS=3, MEMORY_LIMIT='1GB', PRIORITY=LOW, MAX_COST=-1.0);

ACTIVE_STATEMENTS：

隊(duì)列中允許同時(shí)運(yùn)行的查詢數(shù)，即隊(duì)列中允許并發(fā)查詢的最大并發(fā)值。數(shù)據(jù)庫(kù)允許超出ACTIVE_STATEMENTS數(shù)目、但是少于數(shù)據(jù)庫(kù)最大連接數(shù)MAX_CONNECTIONS數(shù)目的鏈接連接到數(shù)據(jù)庫(kù)，但是這部分SQL連接并不會(huì)立刻開始運(yùn)行，而是排隊(duì)等待。

MAX_COST：

查詢計(jì)劃Cost限制。數(shù)據(jù)庫(kù)優(yōu)化器會(huì)為每個(gè)查詢計(jì)算Cost，如果該Cost總量超過了資源隊(duì)列所設(shè)定的的MAX_COST的值，該查詢就會(huì)被拒絕。ADB PG的默認(rèn)配置為0，即不受限制。

Memory Limit：

ADB PG可以通過設(shè)置statement_mem來(lái)決定每條SQL在每個(gè)Segment上使用的內(nèi)存上限。Memory Limit既沒有默認(rèn)值，也可以不指定。在MEMORY_LIMIT參數(shù)沒有被配置時(shí)，一個(gè)資源隊(duì)列中的一條SQL所允許的內(nèi)存大小，由statement_mem參數(shù)決定：

• 如果一個(gè)資源隊(duì)列沒有設(shè)置MEMORY_LIMIT的話，每個(gè)資源所分配到的內(nèi)存大小就是statement_mem的服務(wù)器配置參數(shù)，一個(gè)資源隊(duì)列的可用內(nèi)存大小是根據(jù)statement_mem和ACTIVE_STATEMENTS的計(jì)算結(jié)果。
  
• 當(dāng)資源隊(duì)列有設(shè)置MEMORY_LIMIT時(shí)，單個(gè)SQL所使用的內(nèi)存量會(huì)由隊(duì)列中的平均分配值(MEMORY_LIMIT/ACTIVE_STATEMENTS)和statement_mem中的最大值決定，具體計(jì)算方式可以參考后面實(shí)現(xiàn)章節(jié)。
  

資源隊(duì)列中可以并行執(zhí)行的查詢數(shù)會(huì)受到該隊(duì)列的可用內(nèi)存限制。舉個(gè)例子：對(duì)于隊(duì)列etl，設(shè)置STATEMENTS=3， MEMORY_LIMIT=2.1G；那么在沒有設(shè)置statement_mem的情況下，每個(gè)查詢默認(rèn)使用內(nèi)存700MB。

SQL1進(jìn)入隊(duì)列，使用內(nèi)存700MB，此時(shí)隊(duì)列剩余內(nèi)存1.4G；

SQL2進(jìn)入隊(duì)列，設(shè)置statement_mem為1.0GB，此時(shí)隊(duì)列剩余內(nèi)存為0.4GB；

此時(shí)，隊(duì)列剩余內(nèi)存無(wú)法滿足SQL3的內(nèi)存使用需求（默認(rèn)700GB），那么雖然隊(duì)列中并行查詢數(shù)沒有達(dá)到隊(duì)列限制，SQL3依然無(wú)法執(zhí)行，需要排隊(duì)等待。

PRIORITY：

數(shù)據(jù)庫(kù)運(yùn)行的SQL會(huì)按照其所在資源隊(duì)列的優(yōu)先權(quán)設(shè)置來(lái)共享可用的CPU資源。當(dāng)一個(gè)來(lái)自高優(yōu)先權(quán)隊(duì)列的語(yǔ)句進(jìn)入到活動(dòng)運(yùn)行語(yǔ)句分組中時(shí)，它可以得到可用CPU中較高的份額，同時(shí)也會(huì)降低具有較低優(yōu)先權(quán)設(shè)置隊(duì)列中已經(jīng)在運(yùn)行的語(yǔ)句得到的份額。

查詢的相對(duì)尺寸或復(fù)雜度不影響CPU的分配。如果一個(gè)簡(jiǎn)單的低代價(jià)的查詢與一個(gè)大型的復(fù)雜查詢同時(shí)運(yùn)行，并且它們的優(yōu)先權(quán)設(shè)置相同，它們將被分配同等份額的可用CPU資源。當(dāng)一個(gè)新的查詢變成活動(dòng)時(shí)，CPU份額將會(huì)被重新計(jì)算，但是優(yōu)先權(quán)相等的查詢?nèi)詫⒌玫降攘康腃PU。

例如，管理員創(chuàng)建三個(gè)資源隊(duì)列：streaming、etl、prod，并相應(yīng)地配置為以下優(yōu)先權(quán)：

• streaming?— 低優(yōu)先權(quán)
  
• etl— 高優(yōu)先權(quán)
  
• prod?— 最大優(yōu)先權(quán)
  

當(dāng)數(shù)據(jù)庫(kù)中只有etl隊(duì)列中有查詢1和2同時(shí)運(yùn)行時(shí)，它們有相等份額的CPU，因?yàn)樗鼈兊膬?yōu)先權(quán)設(shè)置相等：

上圖中顯示的百分?jǐn)?shù)都是近似值。高、低和中優(yōu)先權(quán)隊(duì)列的CPU使用并不總是準(zhǔn)確地用這些比例計(jì)算出來(lái)。

當(dāng)一個(gè)streaming隊(duì)列中的查詢開始運(yùn)行時(shí)，在etl隊(duì)列中兩個(gè)查詢依然保持相等的CPU份額，而低優(yōu)先級(jí)的query3則會(huì)以較低CPU份額運(yùn)行。

而當(dāng)最高優(yōu)先級(jí)隊(duì)列prod中有查詢進(jìn)入隊(duì)列之后，其CPU使用會(huì)被調(diào)整以說(shuō)明其最大優(yōu)先權(quán)設(shè)置。它可能是一個(gè)非常簡(jiǎn)單的查詢，但直到它完成前，它都將要求最大份額的CPU。而其他查詢的優(yōu)先級(jí)則會(huì)被調(diào)整為較低的CPU份額。

三 Resource Queue使用

3.1 創(chuàng)建資源隊(duì)列

ADB PG允許用戶使用SQL創(chuàng)建資源隊(duì)列，并指定各類資源限制。使用CREATE RESOURCE QUEUE命令來(lái)創(chuàng)建新的資源隊(duì)列。

創(chuàng)建帶有并發(fā)限制的隊(duì)列

帶有ACTIVE_STATEMENTS設(shè)置的資源隊(duì)列會(huì)限制指派給該隊(duì)列的角色所執(zhí)行的并發(fā)查詢數(shù)量。

CREATE RESOURCE QUEUE etl WITH (ACTIVE_STATEMENTS=3);

這意味著對(duì)于所有被分配到etl資源隊(duì)列的角色，在任意給定時(shí)刻只能有三個(gè)活動(dòng)查詢被運(yùn)行在這個(gè)系統(tǒng)上。如果這個(gè)隊(duì)列已經(jīng)有三個(gè)查詢?cè)谶\(yùn)行并且一個(gè)角色在該隊(duì)列中提交第四個(gè)查詢，則第四個(gè)查詢只有等到一個(gè)槽被釋放出來(lái)后才能運(yùn)行。

創(chuàng)建帶有內(nèi)存限制的隊(duì)列

帶有MEMORY_LIMIT設(shè)置的資源隊(duì)列控制所有通過該隊(duì)列提交的查詢的總內(nèi)存。在與ACTIVE_STATEMENTS聯(lián)合使用時(shí)，每個(gè)查詢被分配的默認(rèn)內(nèi)存量為：MEMORY_LIMIT /ACTIVE_STATEMENTS。

例如，要?jiǎng)?chuàng)建一個(gè)活動(dòng)查詢限制為10且總內(nèi)存限制為2000MB的資源隊(duì)列（每個(gè)查詢將在執(zhí)行時(shí)被分配200MB的Segment主機(jī)內(nèi)存）：

CREATE RESOURCE QUEUE etl WITH (ACTIVE_STATEMENTS=10, MEMORY_LIMIT='2000MB');

另外gp_vmem_protect_limit參數(shù)會(huì)限制一個(gè)Segment上分配的內(nèi)存總大小。該參數(shù)的優(yōu)先級(jí)更高，如果這個(gè)參數(shù)超標(biāo)，查詢可能會(huì)被取消。

設(shè)置優(yōu)先級(jí)

為了控制一個(gè)資源隊(duì)列對(duì)可用CPU資源的消耗，用戶可以指派一個(gè)合適的優(yōu)先級(jí)。

ALTER RESOURCE QUEUE etl WITH (PRIORITY=LOW); ALTER RESOURCE QUEUE etl WITH (PRIORITY=MAX);

3.2 指派角色（用戶）到資源隊(duì)列

一旦創(chuàng)建了一個(gè)資源隊(duì)列，用戶必須把角色（用戶）指派到它們合適的資源隊(duì)列。如果沒有顯式地把角色指派給資源隊(duì)列，它們將進(jìn)入默認(rèn)資源隊(duì)列pg_default。

使用ALTER ROLE或者CREATE ROLE命令來(lái)指派角色到資源隊(duì)列。例如：

ALTER ROLE name RESOURCE QUEUE queue_name; CREATE ROLE name WITH LOGIN RESOURCE QUEUE queue_name;

從資源隊(duì)列移除角色

所有用戶都必須被指派到資源隊(duì)列。如果沒有被顯式指派到一個(gè)特定隊(duì)列，用戶將會(huì)進(jìn)入到默認(rèn)的資源隊(duì)列pg_default。如果用戶想要從一個(gè)資源隊(duì)列移除一個(gè)角色并且把它們放在默認(rèn)隊(duì)列中，可以將該角色的隊(duì)列指派改成none。例如：

ALTER ROLE role_name RESOURCE QUEUE none;

3.3 修改資源隊(duì)列

在資源隊(duì)列被創(chuàng)建后，用戶可以使用ALTER RESOURCE QUEUE命令更改隊(duì)列限制，或使用DROP RESOURCE QUEUE命令移除一個(gè)資源隊(duì)列。

修改資源隊(duì)列配置

ALTER RESOURCE QUEUE命令更改資源隊(duì)列的限制。要更改一個(gè)資源隊(duì)列的限制，可以為該隊(duì)列指定想要的新值。例如：

ALTER RESOURCE QUEUE etl WITH (ACTIVE_STATEMENTS=5); ALTER RESOURCE QUEUE etl WITH (PRIORITY=MAX);

刪除資源隊(duì)列

DROP RESOURCE QUEUE命令可以刪除資源隊(duì)列。要?jiǎng)h除一個(gè)資源隊(duì)列，該隊(duì)列不能有指派給它的角色，也不能有任何語(yǔ)句在其中等待。

DROP RESOURCE QUEUE etl;

四 Resource Queue狀態(tài)監(jiān)控

4.1 查看隊(duì)列中的語(yǔ)句和資源隊(duì)列狀態(tài)

gp_toolkit.gp_resqueue_status視圖允許用戶查看一個(gè)負(fù)載管理資源隊(duì)列的狀態(tài)和活動(dòng)。對(duì)于一個(gè)特定資源隊(duì)列，它展示有多少查詢?cè)诘却\(yùn)行以及系統(tǒng)中當(dāng)前有多少查詢是活動(dòng)的。要查看系統(tǒng)中創(chuàng)建的資源隊(duì)列、它們的限制屬性和當(dāng)前狀態(tài)：

SELECT * FROM gp_toolkit.gp_resqueue_status;

4.2 查看資源隊(duì)列統(tǒng)計(jì)信息

如果想要持續(xù)跟蹤資源隊(duì)列的統(tǒng)計(jì)信息和性能，用戶可以使用pg_stat_resqueues系統(tǒng)視圖來(lái)查看在資源隊(duì)列使用上收集的統(tǒng)計(jì)信息。

SELECT * FROM pg_stat_resqueues;

4.3 查看指派到資源隊(duì)列的角色

要查看指派給資源隊(duì)列的角色，執(zhí)行下列在pg_roles和gp_toolkit.gp_resqueue_status系統(tǒng)目錄表上的查詢：

SELECT rolname, rsqname FROM pg_roles, gp_toolkit.gp_resqueue_status WHERE pg_roles.rolresqueue=gp_toolkit.gp_resqueue_status.queueid;

4.4?查看資源隊(duì)列的等待查詢

用戶可以看到所有資源隊(duì)列的所有當(dāng)前活躍的以及在等待的查詢：

SELECT * FROM gp_toolkit.gp_locks_on_resqueue WHERE lorwaiting='true';

如果這個(gè)查詢不返回結(jié)果，那就意味著當(dāng)前沒有語(yǔ)句在資源隊(duì)列中等待。

4.5 查看活動(dòng)語(yǔ)句的優(yōu)先權(quán)

查看當(dāng)前正在被執(zhí)行的語(yǔ)句并且提供優(yōu)先權(quán)、會(huì)話ID和其他信息：

SELECT * FROM gp_toolkit.gp_resq_priority_statement;

4.6 重置活動(dòng)語(yǔ)句的優(yōu)先權(quán)

用戶可以使用函數(shù)gp_adjust_priority(session_id,statement_count,priority)調(diào)整當(dāng)前正在被執(zhí)行的語(yǔ)句的優(yōu)先權(quán)。使用這個(gè)函數(shù)，用戶可以提升或者降低任意查詢的優(yōu)先權(quán)。例如：

SELECT gp_adjust_priority(12, 10000, 'LOW');

在這個(gè)函數(shù)的參數(shù)中，session_id代表會(huì)話id, statement_count代表要調(diào)整的SQL在session中的序號(hào)，priority是待調(diào)整的優(yōu)先級(jí)。可以通過gp_resq_priority_statement視圖查詢現(xiàn)有語(yǔ)句的上述信息。

select * from gp_toolkit.gp_resq_priority_statement;

五 Resource Queue實(shí)現(xiàn)

ADB PG數(shù)據(jù)庫(kù)是MPP架構(gòu)，整體分為一個(gè)或多個(gè)Master，以及多個(gè)segment，數(shù)據(jù)在多個(gè)segment之間可以隨機(jī)、哈希、復(fù)制分布。在ADB PG中，Resource Queue的資源限制級(jí)別是語(yǔ)句級(jí)別，即在整條SQL執(zhí)行的任何時(shí)刻，不管是否處于事務(wù)中，均會(huì)受到資源隊(duì)列的限制。

如上文所述，Resource Group支持對(duì)并發(fā)、CPU和內(nèi)存等進(jìn)行限制，本節(jié)會(huì)詳細(xì)介紹對(duì)這些資源進(jìn)行限制的實(shí)現(xiàn)細(xì)節(jié)。

5.1 并發(fā)限制

ADBPG數(shù)據(jù)庫(kù)是多進(jìn)程模型，分布式數(shù)據(jù)庫(kù)的每個(gè)節(jié)點(diǎn)會(huì)啟動(dòng)多個(gè)子進(jìn)程，各個(gè)子進(jìn)程通過共享內(nèi)存、共享信號(hào)量、共享消息隊(duì)列的方式實(shí)現(xiàn)進(jìn)程間通信。

Resource Queue基于分布式鎖實(shí)現(xiàn)。在ADBPG中所有的SQL連接首先會(huì)到達(dá)Master節(jié)點(diǎn)，在經(jīng)過解析、優(yōu)化，到達(dá)執(zhí)行器層面時(shí)，會(huì)首先嘗試獲取ResQueueLock類型的排他鎖。

在單個(gè)ADB PG節(jié)點(diǎn)中，同一時(shí)間只能有一個(gè)進(jìn)程獲取到ResQueueLock類型的排他鎖，而每個(gè)進(jìn)程只會(huì)包含單個(gè)線程。

在獲得ResQueueLock類型的排他鎖之后，執(zhí)行SQL的后臺(tái)進(jìn)程會(huì)讀取及更新共享內(nèi)存中的值，特別是隊(duì)列中并發(fā)執(zhí)行語(yǔ)句的計(jì)數(shù)值。若資源充足，則會(huì)在更新完共享內(nèi)存中對(duì)應(yīng)資源隊(duì)列中的資源使用量之后，釋放ResQueueLock，開始SQL的實(shí)際執(zhí)行；

若資源不足，比如當(dāng)前隊(duì)列中正在運(yùn)行的SQL數(shù)量已經(jīng)達(dá)到了所設(shè)定的并發(fā)上限值，對(duì)應(yīng)的后臺(tái)進(jìn)程則會(huì)sleep排隊(duì)等待其他query執(zhí)行完畢后釋放資源。

5.2 內(nèi)存限制

對(duì)于內(nèi)存的限制的實(shí)現(xiàn)方式與對(duì)并發(fā)限制的實(shí)現(xiàn)方式大體是一致的，只是對(duì)于判斷資源隊(duì)列中是否有資源來(lái)運(yùn)行提交的SQL的方式有一些區(qū)別。

對(duì)于某個(gè)Resource Queue中的SQL，能夠使用的內(nèi)存上限計(jì)算如下：

1）如果沒有設(shè)定resource queue的memory_limit值，那么直接取數(shù)據(jù)庫(kù)的statement_mem值；

2）如果設(shè)定了resource queue的memory limit值，則根據(jù)所設(shè)定的resource queue的memory_limit值，計(jì)算資源組能夠使用的內(nèi)存總量；用總量除以resource queue設(shè)定的并發(fā)數(shù)，得到單條SQL所能利用的上限值。再將這個(gè)上限值與statement_mem取一個(gè)最大值，作為SQL最終使用的內(nèi)存上限值。

5.3 CPU限制

Resource Queue的CPU限制是一個(gè)很有意思的實(shí)現(xiàn)。ADB PG專門為Resource Queue CPU限制的功能拉起了一個(gè)專門的進(jìn)程：sweeper進(jìn)程來(lái)監(jiān)控各個(gè)后臺(tái)進(jìn)程的CPU使用，以及調(diào)節(jié)各個(gè)后臺(tái)進(jìn)程的CPU份額。

這個(gè)進(jìn)程是一個(gè)與數(shù)據(jù)庫(kù)高度獨(dú)立的進(jìn)程，它沒有加載一些緩存、資源類的東西，也無(wú)法開啟事務(wù)或者查系統(tǒng)表，它的活動(dòng)就是不停的讀寫共享內(nèi)存，計(jì)算各個(gè)進(jìn)程的CPU使用，更改CPU分配份額。各個(gè)實(shí)際執(zhí)行SQL的后臺(tái)進(jìn)程(backend)會(huì)根據(jù)所計(jì)算的CPU份額去休眠一定的時(shí)間，從而調(diào)節(jié)各個(gè)SQL實(shí)際的CPU使用率。

這個(gè)進(jìn)程的主體流程如上，他的流程非常簡(jiǎn)單，就是不斷地sweep和sleep。

各個(gè)實(shí)際執(zhí)行SQL的backend進(jìn)程在啟動(dòng)時(shí)，會(huì)在共享內(nèi)存中注冊(cè)一些狀態(tài)，并在執(zhí)行過程中執(zhí)行系統(tǒng)調(diào)用getrusage等，更新CPU使用狀態(tài)；sweeper進(jìn)程會(huì)根據(jù)這些共享內(nèi)存狀態(tài)，以及所設(shè)定的資源隊(duì)列CPU利用值，在共享內(nèi)存中更新對(duì)應(yīng)backend進(jìn)程的CPU份額(targetCPU)。而在backend運(yùn)行過程中，則會(huì)調(diào)用BackoffBackend，根據(jù)CPU份額來(lái)進(jìn)行一段時(shí)間的休眠，從而調(diào)節(jié)整體的CPU利用率。

在運(yùn)行過程中，分布式數(shù)據(jù)庫(kù)的每個(gè)計(jì)算節(jié)點(diǎn)都會(huì)有一個(gè)sweeper進(jìn)程來(lái)調(diào)節(jié)每個(gè)節(jié)點(diǎn)的CPU調(diào)用，使資源隊(duì)列的CPU配置全局有效。

六 總結(jié)

資源管理對(duì)于數(shù)據(jù)庫(kù)集群的多租戶管理、資源細(xì)粒度分配具有很重要的價(jià)值。Resource Queue能夠?qū)Ψ植际綌?shù)據(jù)庫(kù)進(jìn)行整體的資源管理和控制，在多租戶隔離、保障數(shù)據(jù)庫(kù)整體平穩(wěn)運(yùn)行具有一定的價(jià)值。

除了Resource Queue的資源管理方式外，ADB PG還支持 Resource Group 的資源管理方式，能夠進(jìn)行更精細(xì)的資源控制。Resource Group現(xiàn)已在專有云環(huán)境提供使用，后續(xù)會(huì)逐步在公有云提供能力。后續(xù)我們會(huì)介紹Resource Group的基本使用和最佳實(shí)踐。

原文鏈接：https://developer.aliyun.com/article/784139?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的实操指南 | Resource Queue如何实现对AnalyticDB PostgreSQL的资源管理？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。