摘要： 本文主要對DMS資源池隊列阻塞告警進行介紹，以及對其背後涉及的內核原理進行介紹。
本文分享自華爲雲社區《DMS資源池隊列阻塞告警及原理介紹》，作者： codefulture。
一、概述
資源池隊列阻塞告警旨在通過一定的檢測機制，提前對資源池隊列阻塞的情況告知用戶，避免影響正常業務。然而如何得知資源池隊列阻塞就需要了解其背後的運行原理，本文所述僅僅是一種檢測方式，並非唯一絕對的，也可以通過其他方式檢測資源池隊列阻塞。
二、資源管理/負載管理概述
數據庫系統的負載管理和資源管理，在整個系統中起着很重要的作用。
1. 負載管理簡介：雙層排隊機制
DWS的負載管理分爲兩層，第一層爲CN的全局併發控制，第二層爲資源池級別的併發控制。在通過第一層控制的時候，會繼續向前走到第二層資源池控制，根據資源池當前的負載資源情況決定作業繼續執行或者排隊。
DWS併發控制邏輯示意圖如下：
2. 資源管理簡介
影響一個集羣的資源包括內存、CPU、磁盤I/O和存儲空間等。GaussDB（DWS）提供了一系列資源負載管理手段，通過對資源的集中管控，可以有效避免作業佔用資源的衝突，高優先級作業優先執行，以及用戶間的資源隔離。其中：
- CPU、I/O等計算資源是通過資源池進行管理。
- 內存管理通過數據庫系統參數、GUC參數，和資源池等進行控制。
- 數據存儲空間是通過創建用戶指定。
3. 總結
通過上面的介紹可以總結出：負載管理是爲了解決排隊的問題，將任務能夠平均到不同的cn或資源池上；然而在實際應用中，作業是否排隊與資源池的資源有着直接關係；資源管理通過一定手段提高資源的利用率。
資源池是GaussDB(DWS)進行負載管理的基本單元，負責管理業務運行所需的系統資源（包括CPU、I/O和內存），並提供SQL的併發控制功能。
三、基於資源池的負載管理
GaussDB(DWS)資源負載管理的核心是資源池，資源池提供多種屬性可以控制內存、IO和CPU資源的控制，基於優先級調度機制實現資源管理和分配，對用戶業務提供資源負載管理服務。基於資源池的資源負載管理的範圍包括：併發管理、優先級調度。
1. 控制組（Controller Group）
在介紹資源池之前需要先了解控制組的相關概念。cgroups是Linux內核提供的一種可以限制進程所使用資源的機制，全稱是control groups，cgroups爲每種可以控制的資源定義了一個子系統。
圖中是控制組的一個掛載樹，從最上層開始，就分爲了兩部分，一部分是屬於Gaussdb的資源，一部分是留給系統其他進程使用的資源，我們使用的資源如圖所示，都是掛載到Gaussdb:gaussdba的，其中第一層又分爲兩個控制組，Backend用來預留資源給數據庫常駐的各個工作線程，Class控制組的資源用來分配給各個用戶進行作業執行。
2. 資源池（Resource Pools）
資源負載管理的工作原理如圖所示。
資源池通過綁定控制組進行實現資源的分配，作業的優先級和其關聯的資源池的資源數量有關。一般情況下，我們認爲作業關聯到的資源池擁有的資源數量越多，則其優先級越高，因爲該作業能夠擁有更多的資源去執行。如果一個資源池擁有的資源比例發生了變化，則其對應的優先級也會發生變化，可以通過調整資源池中屬性來修改優先級。
在開啓資源負載管理功能之後，default_pool是由系統自動創建，當一個會話或者用戶沒有指定關聯的資源池時，都會被默認關聯到default_pool，並且default_pool默認綁定到DefaultClass:Medium控制組，並且不限制所關聯的業務併發數，而且一個控制組可以綁定多個資源池。
3. 關聯作業
在使用資源池對系統資源進行分配後，需要將作業關聯到某個資源池上，才能實現對業務的負載管理。把資源池與用戶進行關聯後，該用戶下執行的所有作業都會自動關聯到該資源池下。如果該用戶沒有綁定資源池，則任務進入默認資源池default_pool的等待隊列。
四、query band 負載識別
當一個控制組關聯的資源池有多個的時候，用戶下發的作業應該使用哪個資源池來執行任務呢？如果用戶已經下發了很多作業，但是某個新作業又非常緊急怎麼辦？類似的問題可能還有很多，那麼如何解決上述的問題呢，這時候我們就要藉助一個手段：query band。
GaussDB(DWS)實現基於query band的負載識別和隊列內優先級控制，一方面提供了更爲靈活的負載識別手段，可根據作業類型、應用名稱、腳本名稱等識別負載隊列，使用戶根據業務場景可靈活配置query band識別隊列；另一方面實現了隊列內作業下發優先級控制。管理員用戶可根據業務場景及作業類別配置query_band所關聯隊列及估算內存限制等實現更爲靈活的負載控制與資源管控。
query band目前支持行爲有：關聯資源池(respool)、隊列內優先級(priority)。
1. query band關聯隊列內優先級
query_band支持關聯作業優先級，支持高中低(High/Medium/Low)三個優先級，同時提供Rush作爲特殊優先級，默認優先級爲Medium。
隊列內排隊優先級三種情況：
- 靜態負載管理場景下，CN併發不足時，觸發CN全局隊列排隊，CN全局隊列爲優先級隊列。
- 動態負載管理場景下，DN內存不足時，觸發CCN全局排隊，CCN全局隊列爲優先級隊列。
- 資源池併發或內存不足時，觸發資源池排隊，資源池隊列爲優先級隊列。
如果業務未配置query band或用戶未將query band關聯行爲時，作業會默認使用用戶關聯隊列和隊列內優先級。
從上述的介紹可以理解爲，query band可以設置任務在資源池中的執行順序，優先級高的任務優先執行；如果出現資源不足等不能立刻執行任務的情況，則會觸發排隊優先級，優先級高的優先在隊列中排隊。
2. query band關聯資源池
作業執行時，若query_band指定了隊列，則使用query_band關聯的隊列，否則使用用戶關聯的隊列。
五、原理梳理
六、資源池隊列阻塞告警在DMS中的實現
1. 資源池隊列阻塞的判定
通過上述的介紹，我們已經瞭解了資源負載管理的基本原理，那麼如何判定資源池隊列阻塞呢？影響作業在資源池運行的要素有併發數、CPU和內存等資源限制，也可能是由於集羣狀態異常導致的，下面我們將從以下兩種情況進行分析。
第一種情況，如果併發或CPU等資源不夠用，會出現資源池隊列排隊，但並非阻塞的狀態，因爲作業結束後，處於隊首的作業會開始運行，那麼資源池隊列中的作業是動態變化的。
第二種情況，如果用戶下發的作業就是特別的複雜，運行時間可能有幾十分鐘，那麼在默認情況下，資源池隊列中的作業始終不變，但是如果用戶在調整作業優先級之後，作業能夠正常運行，也不能說明資源池是阻塞的。
結合以上兩種情況，我們結合資源池隊列中作業的狀態，以及不同優先級作業在資源池的運行情況判斷資源池是否阻塞。首先我們將範圍限定在默認資源池中，因爲默認資源池是開啓資源管理功能後又系統創建，代表系統的狀態；其次資源池執行任務異常，必定引起資源池隊列出現排隊現象，且處於隊首的任務始終不變，排隊時間增加；並且運行在資源池上所有優先級的作業都不能正常下發。
總結下來就是，在一定時間內，集羣默認資源池隊列中處於各個優先級的作業不變即可判定爲資源池隊列發生阻塞。
2. 資源池隊列阻塞告警的實現
資源池隊列阻塞告警是基於DMS原有告警功能進行實現，實現流程依舊是分爲數據上報與採集—>告警判斷—>上報告警。信息採集線程會將資源池中任務的狀態實時上報，形成原始指標落盤，然而我們需要判斷不同優先級的任務排隊情況，直接用原始數據進行處理會比較繁瑣，所以我們藉助一個定時任務，定時採集原始指標數據，並進行整合、轉置，最後我們用整合後的數據，判斷是否發生了資源池阻塞。
圖片中的20分鐘爲默認時間，用戶可以根據在自定義配置判斷的時長。
3. 資源池隊列阻塞的原因
- 資源池併發數
如果用戶設置的資源池併發數過小，會出現資源池隊列排隊，此時應當調大資源池併發數量。
- 資源不足
重新分配資源池的各項資源，包括CPU、內存、磁盤等。
還有其他的場景和解決方式，可以參考下方的博客。
參考文章
GaussDB(DWS) 數據庫智能監控系統告警框架上線啦！
GaussDB(DWS) 負載管理簡單介紹以及作業排隊處理方法
玩轉GaussDB(DWS)資源負載管理系列 — DWS資源負載管理的原理