一文詳述DMS資源池佇列阻塞告警及原理

摘要：  本文主要對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資源負載管理的原理

 

 

點選關注，第一時間瞭解華為雲新鮮技術~