GaussDB(DWS) 負載管理簡單介紹以及作業排隊處理方法

概述

數據庫系統的負載管理和資源管理，在整個系統中起著很重要的作用，比如很多用戶的業務壓力過大時，有時會導致連接數量被占滿，有時會導致某種計算資源被占滿，有時會導致存儲空間被占滿，這些情況都會導致整個集群進入異常甚至不可用的狀態：正在執行的作業互相爭搶CPU，會導致大家都不能好好執行；大量作業執行時，占用大量內存，很容易觸發到內存瓶頸，造成作業內存不可用問題，導致業務報錯等等。在不進行并發控制的情況下，這些情況都很可能會出現，影響到正常業務。

本文用來總結一些GaussDB(DWS)在實際應用過程中，可能出現的各種作業排隊的情況，以及出現排隊時，我們應該怎么去判斷是否正常，調整一些參數，讓資源分配與負載管理更符合當前的業務；或者在作業阻塞的時候，怎么去處理這些情況，讓業務立刻恢復正常。

本文分為以下幾個小節去介紹并解答以上問題：

一、負載管理簡介：雙層排隊簡述

二、常用視圖以及使用方法介紹

三、負載管理常見問題以及處理

四、部分負載管理配置方案介紹

五、小結

一、負載管理簡介：雙層并發控制簡述

DWS的負載管理分為兩層，第一層為cn的全局并發控制，第二層為資源池級別的并發控制。在通過第一層控制的時候，會繼續向前走到第二層資源池控制，根據資源池當前的負載資源情況決定作業繼續執行或者排隊。

DWS并發控制邏輯示意圖如下：

從本圖的邏輯我們可以看到，實際作業執行中，可能會在兩種隊列中排隊：

一種是全局隊列（global queue），這種隊列不區分簡單和復雜作業，也不區分是DDL或者是普通語句，

一種是資源池隊列(resource pool queue),用戶下發的一般語句會根據資源消耗估算以及復雜程度在這里進行判斷是否排隊。

在兩層隊列的過濾下，DWS會篩選出當前能執行的語句，使其正常運行，運行時也會受到其所屬資源池資源的限制（只能使用資源池配置的CPU、內存、IO配額）。

二、常用視圖以及使用方法介紹

這里介紹幾個常用視圖以及SQL語句，可以迅速判斷目前的業務出現問題的原因，受限根據以下視圖可以看到目前的作業是不是在排隊，之后要迅速分析為什么在排隊，是因為負載管理各個參數配置問題，還是因為正在執行的語句占據了過多的資源導致的排隊。

pgxc_stat_activity(pg_stat_activity)

常用語句：

#查詢當前執行時間最長的語句的排隊狀態，query_id(數據庫中作業的唯一標識)，以及詳細的語句信息。

select coorname,usename, current_timestamp-query_start as duration, enqueue,query_id,query from pgxc_stat_activity where state='active' and usename <> 'Ruby' order by duration desc;

根據該語句可以迅速判斷出哪些語句執行時間很長，是什么樣的語句執行很慢以及該語句的query_id，便于迅速進入下一步排查。

執行結果如下：

上圖解說：圖中為在沒有作業的情況下查詢，可以看到有幾個WLM的語句已經執行了很多，不過這兩個是內部常駐線程，所以不影響業務，也不會占用連接數等數據庫資源。

其余的行可以看到有bi用戶，在執行一些作業，時間大概1-6分鐘左右。

pg_session_wlmstat (記錄每個cn的語句執行情況，資源使用情況，排隊情況等信息)

常用語句：

#查詢每個用戶下的作業執行情況，排隊情況以及作業的復雜情況和內存消耗情況。

select usename,enqueue,datname,status,attribute,count(*),sum(statement_mem) from pg_session_wlmstat group by 3,1,2,4,5 order by 1,3,4,5 ;

執行結果如下：

上圖解說：

上圖中說明當前連接的cn中有用戶名為usr1的用戶執行作業，并且在資源池上排隊（第一節介紹的resourcepool隊列），數據庫為postgres，作業在排隊所以當前status為pending狀態。

其他字段包括作業的屬性和當前使用內存資源的總和情況（根據該數值可以看出是否因為內存資源不足而進入排隊狀態）。作業在排隊時候不涉及到資源消耗，因此可能沒有具體數值。

pgxc_thread_wait_status（查看數據庫中各個線程的執行情況，當前在等待哪一步驟執行完成，在哪個實例等待，都可以通過該視圖查詢）;

常用語句：

#在根據pgxc_stat_activity查詢到具體執行時間長的語句之后，可以根據本視圖查詢：

select * from pgxc_thread_wait_status where query_id = xxxxxxxx;

該語句可以查看執行慢語句的阻塞點，語句卡住時，可以通過該語句查看語句卡在了哪個步驟。

舉例如下：

上圖可以看到作業在wait io，此時可以檢查下磁盤的讀寫速度是否，raid卡讀寫策略是否正常等等。

當出現排隊的時候，wait_status一般的狀態是waiting in ccn queue/waiting resourcepool queue等狀態。

查詢并發數量的方法，就是查看pgxc_stat_activity中，狀態（state字段）是active的語句，enqueue字段為null的語句，除此之外，idle in transaction之類狀態的語句，也會占用一個并發數量，因為一個事務塊的業務還未提交，自然也算是正在執行的業務，對于這種情況，后續可以考慮進行一個處于此類狀態的超時時間的控制。

三、負載管理常見問題

一般當業務上發現任務阻塞時，可以從后臺查詢部分語句排查目前的情況，此時要先看下現象上是什么情況，一般并發控制有以下幾種現象，暫時先列出這么多，后續繼續補充：

1.?? 業務反饋無法連接到數據庫，比如DS連接一直轉圈，過一段時間之后會超時報錯。

此時可以開始排查當前的配置情況，一般連接不到數據庫，其實是一種表象，主要是因為作業已經進入了排隊的狀態，語句本身就有很多在排隊，無法執行，此時用ds連接之后，ds本身就會下發語句查詢一些系統表之類的信息，所以也會進入排隊的狀態，在客戶層面的影響就是ds一直處于一個連接中的狀態，實際上是ds的連接在數據庫中。

查詢參數配置，看當前每個cn可以接受的最大并發數量是多少：

show max_active_statements;

如果當前cn的活躍作業超過這個參數，會出現語句排隊的情況，主要排隊情況為waiting in global queue，如下圖所示，下圖情況中，max_active_statements=6。

查看業務連接是否主要只連接一個cn，可以同樣通過查詢pgxc_stat_activity判斷coorname，查看是否大量的語句都是集中在某一個cn上執行，當語句下發集中在某個cn上時，這個cn的并發數量也只是max_active_statements設置的大小，舉個例子：如果業務連接3個cn，每個cn的max_active_statements設置都是10，那么最大可以同時運行30個作業；如果這30個作業都下發到一個cn上，那么就有20個排隊，同時只能執行10個，會大大影響執行效率，同時也會造成這種看似無法連接到該cn的現象。

解決方法：

業務負載不均：配置LVS，均衡業務，避免負載不均導致的排隊。

max_active_statements參數設置過小：在資源負載允許的情況下繼續調大，如果資源達到瓶頸，繼續放大可能會導致資源爭搶，效果不大。

連接被空閑事務占用：如上圖中情況，可以看到有很多連接的狀態都是idle in transaction，這種狀態處于事務塊完成但是沒有提交，也會占用一個并發，導致其余作業并發量減小，導致排隊。此類情況需要排查業務應用的執行情況，整改業務，避免處于這種空閑還占用并發的情況。嚴重阻塞業務的情況，緊急處理可以將該類語句直接terminate掉。

確實已經有很多作業在執行，資源使用也已經達到一個瓶頸，這時候就需要去擴容或者降低業務量，來避免這種情況出現。

2.?? 作業長時間執行不出來，并且有很多作業在排隊，整體業務受到阻塞。

此類情況可以繼續使用上述查詢pgxc_stat_activity的語句，查看語句的運行情況，結果可能如下：

如圖：圖中最下方的兩個作業，執行時間已經達到了11小時，但是仍然沒有執行完，后面還有未執行的語句在排隊。整體對于客戶來說就是數據庫已經hang死了，什么作業都執行不出來。

排查步驟

排查當前集群是否在使用動態自適應功能，查看如下參數：

show enable_dynamic_workload; //查看該參數目前是否為打開狀態（2020年的版本都是默認打開）

如果該參數打開，那么就要查看這幾個正在運行作業目前的內存使用情況，大概率正是因為這幾個作業一直使用著內存不釋放，才會出現整體的排隊情況。

通過連接cn 5001查詢視圖：

select * from pg_session_wlmstat where threadid = $query_id;

該視圖可以看到某個語句使用了多大的內存，statement_mem字段可以看到我這個語句是使用了1G，但是實際情況中，1個語句使用幾十個語句的情況很多。當一個或者幾個語句的內存達到整個集群的總體可用內存上限，或者達到資源池上限的時候，就會使這些語句后面的語句開始排隊。資源不放，排隊不止。

處理方法

應急處理：及時將卡住的語句terminate，釋放其占用的資源，后續進行優化之后再執行，優化手段很多，包括計劃調優，analyze等操作，都可以避免一個語句占用太大內存，也可以提升執行效率。

3.? ?全局資源可用內存很多，資源使用很小，并發數量也沒有達到上限，但是查詢顯示很多作業處于排隊狀態。

舉例：查詢pgxc_stat_activity時，語句的執行狀態如下：可以看到，所有語句都在waiting in ccn queue，只有兩個語句在運行。此時集群設置的max_active_statements是40，但是該用戶實際活躍數量只有2個。

舉例：查詢pgxc_stat_activity時，語句的執行狀態如下：可以看到，所有語句都在waiting in ccn queue，只有兩個語句在運行。此時集群設置的max_active_statements是40，但是該用戶實際活躍數量只有2個。

首先，出現出現waiting in ccn queue的情況，就一定是開啟了內存自適應功能(enable_dynamic_workload=on)。此時只有兩種情況，第一種是全局資源不足，會排隊，第二種是用戶所屬的資源池內存不足，也會排隊。

根據圖中的現象，我們看到很多語句都在排隊，這時候要查詢一個排隊視圖：select * from pg_stat_get_workload_struct_info();

這個視圖可以清晰看到作業是在哪里排隊：

首先，上圖中有totalsize，這個就是總體可用的最大內存，freesize_limit:執行語句可用的最大內存，freesize:當前可用的最大內存。

所以可以得出結論，此時不是在全局排隊，全局內存freesize足夠，那么作業就是在資源池排隊，資源池排隊也會顯示waiting in ccn queue。

此時查詢pg_session_wlmstat視圖，可以看到正在運行的為dw用戶，正在運行的語句占用的內存為兩條各1G。

可以通過界面或者后臺查看一下，這個用戶對應的租戶上，是不是做了內存資源限制：

查看租戶界面內存配置如下：

可以看到圖中給這個租戶或者說給這個用戶所在的資源池配置了10%的內存配額，一共是2277MB，即2G左右。

因此這種場景下，內存資源只能滿足當前兩個語句的執行，其余屬于該用戶的語句都會進行排隊。

處理辦法：

方法一、此類問題，若在資源允許的情況下，可以適當調大租戶相關的內存資源，讓更多語句能夠同時運行。

方法二、優化相關語句的執行效率，縮短執行時間，讓語句可以高效執行，避免大量堆積。

4.執行的作業基本都是一個用戶的，其余用戶的作業基本都在排隊中無法執行。

舉例：之前某局點出現高并發DDL的情況，該類高并發DDL在全局并發計數中會受到統計，占用max_active_statements中的并發數量。

比如：max_active_statements=20，其中某用戶一直持續不停地下發DDL，此時在DWS設計ap場景并未涉及此類場景。會出現該20個并發設置普遍被該用戶占用的情況，其他用戶可能出現連不上的情況。

這種場景下，即時再調大并發，也會再被該用戶的DDL語句占用。

處理方案：

針對高并發DDL的不合理業務場景進行優化，比如把連續創建刪除臨時表的動作，改為對永久表的操作，此時就可以極大幅度減少DDL并發數量，保證自身業務以及其余用戶業務的正常連接和運行。

四、部分場景配置方案

1. 限制單用戶并發

用戶的作業分為以下幾種，DDL/DML/以及常規查詢，在DWS的視角中，常規查詢有分為簡單查詢和復雜查詢。

對于DWS的兩層管控，受到第一層管控的有DDL、start transaction、DML、常規查詢等，基本是所有語句，只有內部線程的語句（比如WLM線程）以及超級用戶權限的用戶執行的作業。

受到第二層管控的語句，主要是可以從優化器獲取到具體執行計劃以及執行代價的語句。

除了DDL/start transaction 之類的語句，以及部分白名單語句，此類語句都是視為基本不消耗資源，并且不會造成阻塞的語句。

針對目前的管控機制來說，可以將單個用戶關聯到一個單獨的資源池，這個資源池不設置內存配置，只設置并發配置，達到進行作業管控的效果。

具體步驟及解釋如下：

1.在所有節點創建好控制組

gs_ssh -c "gs_cgroup -c -S class_a"

gs_ssh -c "gs_cgroup -c -S class_a -G workload_a"

2.創建業務資源池（此時可以同步設置max_dop參數，active_statements會限制復雜作業的并發數量，max_dop參數會限制簡單作業的并發數量）

create resource pool p1 with (control_group="class_a:workload_a");

alter resource pool p1 with (active_statements=10,mem_percent=0,max_dop=1);

3.關聯用戶與該資源池

ALTER USER testuser RESOURCE POOL 'p1';

五、小結

并發管理的用處，主要是為了防止用戶跑太多的作業，導致集群負載過大，資源發生爭搶，系統不能穩定運行，會因為資源出現各種問題，CPU/內存/IO，哪一個都是讓人頭疼的問題，并發控制也可以同步控制某一個用戶的并發作業，避免因為一個用戶的作業數量太大，導致其他用戶在使用數據庫的時候出現問題。

負載管理最主要的現象就是會出現作業排隊的情況，排隊是否合理，是否因為不合理的參數配置導致大量的業務阻塞；或者配置正常，但是沒有達到上限就出現排隊，本文的主要目的就是解決此類問題，或者及時定界到是什么原因導致了阻塞。

實際使用過程中，許多時候出現排隊的情況，都可能和正在執行的語句有關，正在執行的語句占用著這個位置，又執行不完，其余語句自然會排隊。因此我們碰到語句大量阻塞的情況，要迅速定界到是因為什么而造成阻塞，怎么樣能恢復正常使用。找到問題的語句后，要及時去將它做一些適當的調優，避免再次執行到這個語句，還會出現一樣的情況。

EI企業智能 Gauss AP 數據倉庫服務 GaussDB(DWS)

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。