DMS資源池隊列阻塞告警及原理介紹

資源池隊列阻塞告警旨在通過一定的檢測機制，提前對資源池隊列阻塞的情況告知用戶，避免影響正常業務。然而如何得知資源池隊列阻塞就需要了解其背后的運行原理，本文所述僅僅是一種檢測方式，并非唯一絕對的，也可以通過其他方式檢測資源池隊列阻塞。

數據庫系統的負載管理和資源管理，在整個系統中起著很重要的作用。

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

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

影響一個集群的資源包括內存、CPU、磁盤I/O和存儲空間等。GaussDB（DWS）提供了一系列資源負載管理手段，通過對資源的集中管控，可以有效避免作業占用資源的沖突，高優先級作業優先執行，以及用戶間的資源隔離。其中：

CPU、I/O等計算資源是通過資源池進行管理。

內存管理通過數據庫系統參數、GUC參數，和資源池等進行控制。

數據存儲空間是通過創建用戶指定。

通過上面的介紹可以總結出：負載管理是為了解決排隊的問題，將任務能夠平均到不同的cn或資源池上；然而在實際應用中，作業是否排隊與資源池的資源有著直接關系；資源管理通過一定手段提高資源的利用率。

資源池是GaussDB(DWS)進行負載管理的基本單元，負責管理業務運行所需的系統資源（包括CPU、I/O和內存），并提供SQL的并發控制功能。

GaussDB(DWS)資源負載管理的核心是資源池，資源池提供多種屬性可以控制內存、IO和CPU資源的控制，基于優先級調度機制實現資源管理和分配，對用戶業務提供資源負載管理服務。基于資源池的資源負載管理的范圍包括：并發管理、優先級調度。

在介紹資源池之前需要先了解控制組的相關概念。cgroups是Linux內核提供的一種可以限制進程所使用資源的機制，全稱是control groups，cgroups為每種可以控制的資源定義了一個子系統。

圖中是控制組的一個掛載樹，從最上層開始，就分為了兩部分，一部分是屬于Gaussdb的資源，一部分是留給系統其他進程使用的資源，我們使用的資源如圖所示，都是掛載到Gaussdb:gaussdba的，其中第一層又分為兩個控制組，Backend用來預留資源給數據庫常駐的各個工作線程，Class控制組的資源用來分配給各個用戶進行作業執行。

資源負載管理的工作原理如圖所示。

資源池通過綁定控制組進行實現資源的分配，作業的優先級和其關聯的資源池的資源數量有關。一般情況下，我們認為作業關聯到的資源池擁有的資源數量越多，則其優先級越高，因為該作業能夠擁有更多的資源去執行。如果一個資源池擁有的資源比例發生了變化，則其對應的優先級也會發生變化，可以通過調整資源池中屬性來修改優先級。

在開啟資源負載管理功能之后，default_pool是由系統自動創建，當一個會話或者用戶沒有指定關聯的資源池時，都會被默認關聯到default_pool，并且default_pool默認綁定到DefaultClass:Medium控制組，并且不限制所關聯的業務并發數，而且一個控制組可以綁定多個資源池。

在使用資源池對系統資源進行分配后，需要將作業關聯到某個資源池上，才能實現對業務的負載管理。把資源池與用戶進行關聯后，該用戶下執行的所有作業都會自動關聯到該資源池下。如果該用戶沒有綁定資源池，則任務進入默認資源池default_pool的等待隊列。

當一個控制組關聯的資源池有多個的時候，用戶下發的作業應該使用哪個資源池來執行任務呢？如果用戶已經下發了很多作業，但是某個新作業又非常緊急怎么辦？類似的問題可能還有很多，那么如何解決上述的問題呢，這時候我們就要借助一個手段：query band。

GaussDB(DWS)實現基于query band的負載識別和隊列內優先級控制，一方面提供了更為靈活的負載識別手段，可根據作業類型、應用名稱、腳本名稱等識別負載隊列，使用戶根據業務場景可靈活配置query band識別隊列；另一方面實現了隊列內作業下發優先級控制。管理員用戶可根據業務場景及作業類別配置query_band所關聯隊列及估算內存限制等實現更為靈活的負載控制與資源管控。

query band目前支持行為有：關聯資源池(respool)、隊列內優先級(priority)。

query_band支持關聯作業優先級，支持高中低(High/Medium/Low)三個優先級，同時提供Rush作為特殊優先級，默認優先級為Medium。

隊列內排隊優先級三種情況：

靜態負載管理場景下，CN并發不足時，觸發CN全局隊列排隊，CN全局隊列為優先級隊列。

動態負載管理場景下，DN內存不足時，觸發CCN全局排隊，CCN全局隊列為優先級隊列。

資源池并發或內存不足時，觸發資源池排隊，資源池隊列為優先級隊列。

如果業務未配置query band或用戶未將query band關聯行為時，作業會默認使用用戶關聯隊列和隊列內優先級。

從上述的介紹可以理解為，query band可以設置任務在資源池中的執行順序，優先級高的任務優先執行；如果出現資源不足等不能立刻執行任務的情況，則會觸發排隊優先級，優先級高的優先在隊列中排隊。

作業執行時，若query_band指定了隊列，則使用query_band關聯的隊列，否則使用用戶關聯的隊列。

通過上述的介紹，我們已經了解了資源負載管理的基本原理，那么如何判定資源池隊列阻塞呢？影響作業在資源池運行的要素有并發數、CPU和內存等資源限制，也可能是由于集群狀態異常導致的，下面我們將從以下兩種情況進行分析。

第一種情況，如果并發或CPU等資源不夠用，會出現資源池隊列排隊，但并非阻塞的狀態，因為作業結束后，處于隊首的作業會開始運行，那么資源池隊列中的作業是動態變化的。

第二種情況，如果用戶下發的作業就是特別的復雜，運行時間可能有幾十分鐘，那么在默認情況下，資源池隊列中的作業始終不變，但是如果用戶在調整作業優先級之后，作業能夠正常運行，也不能說明資源池是阻塞的。

結合以上兩種情況，我們結合資源池隊列中作業的狀態，以及不同優先級作業在資源池的運行情況判斷資源池是否阻塞。首先我們將范圍限定在默認資源池中，因為默認資源池是開啟資源管理功能后又系統創建，代表系統的狀態；其次資源池執行任務異常，必定引起資源池隊列出現排隊現象，且處于隊首的任務始終不變，排隊時間增加；并且運行在資源池上所有優先級的作業都不能正常下發。

總結下來就是，在一定時間內，集群默認資源池隊列中處于各個優先級的作業不變即可判定為資源池隊列發生阻塞。

資源池隊列阻塞告警是基于DMS原有告警功能進行實現，實現流程依舊是分為數據上報與采集—>告警判斷—>上報告警。信息采集線程會將資源池中任務的狀態實時上報，形成原始指標落盤，然而我們需要判斷不同優先級的任務排隊情況，直接用原始數據進行處理會比較繁瑣，所以我們借助一個定時任務，定時采集原始指標數據，并進行整合、轉置，最后我們用整合后的數據，判斷是否發生了資源池阻塞。

圖片中的20分鐘為默認時間，用戶可以根據在自定義配置判斷的時長。

資源池并發數

如果用戶設置的資源池并發數過小，會出現資源池隊列排隊，此時應當調大資源池并發數量。

資源不足

重新分配資源池的各項資源，包括CPU、內存、磁盤等。

還有其他的場景和解決方式，可以參考下方的博客。

參考文章

GaussDB(DWS) 數據庫智能監控系統告警框架上線啦！

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

玩轉GaussDB(DWS)資源負載管理系列 — DWS資源負載管理的原理

想了解GuassDB(DWS)更多信息，歡迎微信搜索“GaussDB DWS”關注微信公眾號，和您分享最新最全的PB級數倉黑科技，后臺還可獲取眾多學習資料哦~

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

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

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