帶你掌握數倉的作業級監控TopSQL

摘要：目前TopSQL功能被用戶廣泛使用，是性能定位、劣化分析、審計回溯等重要的基石，為用戶提供覆寫記憶體、耗時、IO、網路、空間等多方面的監控能力，

本文分享自華為云社區《GaussDB(DWS)監控工具指南（一）作業級監控TopSQL》，作者：幕后小黑爪 ，

1、引言：

監控系統是智能化管理和自動化運維的基石，可以為資源規劃，故障排查，性能優化提供至關重要的資料支持，GaussDB(DWS)作為企業級數倉，為用戶提供了一整套覆寫實體級、用戶級、作業級的資源監控能力，其中，作業級監控（下文統稱為TopSQL）主要是對運行作業的監控，包括了實時運行作業的相關資訊，歷史運行作業的相關資訊等，它收集的資料來源于資料庫內部，為用戶提供了實時監控資料庫的能力，

目前TopSQL功能被用戶廣泛使用，是性能定位、劣化分析、審計回溯等重要的基石，為用戶提供覆寫記憶體、耗時、IO、網路、空間等多方面的監控能力，

本文以數倉813版本作為基線，對TopSQL進行介紹，

2、TopSQL功能介紹

對于用戶而言，資料庫是個黑盒，輸入SQL陳述句，輸出預期結果，在此程序中，用戶關心兩點：

• 輸出結果是否符合預期;
• 陳述句要多久跑完，

關于第一個問題，用戶需要關注下SQL陳述句寫的是否合理，而對于第二個問題，普通用戶可以通過explain等手段分析作業的執行計劃，然而企業用戶的SQL作業耗時久，影響較大，重跑代價較高，無法額外通過explain performance等手段進行分析，此時TopSQL可以幫助用戶打開資料庫黑盒，查看作業執行的實時情況和歷史情況，便于用戶分析資料庫的情況，

TopSQL功能主要通過視圖進行承載，如下表所示，本文以query級別的視圖為例進行說明，

使用TopSQL功能需要sysadmin權限，此外，用戶需先檢查下TopSQL功能是否開啟，涉及TopSQL的資料庫GUC引數包括：

• ENABLE_RESOURCE_TRACK (ON)

是否開啟監控功能，實時TopSQL的總開關，關閉之后實時TopSQL將不再進行記錄，更不會在歷史TopSQL中出現，

• RESOURCE_TRACK_COST(0)

設定對當前會話的陳述句進行資源監控的最小執行代價，

• RESOURCE_TRACK_LEVEL(QUERY)

設定當前會話的資源監控的等級，默認為query級別，

• RESOURCE_TRACK_DURATION(60S)

設定實時TopSQL中記錄的陳述句執行結束后進行歷史資訊轉存的最小執行時間，當執行完成的作業，其執行時間不小于此引數值時，作業資訊會從實時視圖（以STATISTICS為后綴的視圖）轉存到相應的歷史視圖

• ENABLE_RESOURCE_RECORD(ON)

設定是否開啟資源監控記錄歸檔功能，開啟時，對于執行結束的記錄，會分別被歸檔到相應的INFO視圖，CN和DN都需要設定上，

• TOPSQL_RETENTION_TIME(30)

設定歷史TopSQL中GS_WLM_SESSION_INFO和GS_WLM_OPERATOR_INFO表中資料的保存時間，單位為天，

引數正確設定后，TopSQL會記錄用戶的SQL陳述句執行程序中的相關資訊，用戶可以使用TopSQL的視圖篩選出執行時間較長的作業，專注于慢SQL的分析，

TopSQL功能分為實時TopSQL和歷史TopSQL，以query級別為例，當需要查看正在運行的作業時，用戶可查看實時TopSQL視圖GS_WLM_SESSION_STATISTICS和PGXC_WLM_SESSION_STATISTICS，若需要對已經執行完成的作業進行分析，可查詢歷史TopSQL視圖GS_WLM_SESSION_ HISTORY和PGXC_WLM_SESSION_ HISTORY，其中GS_開頭的可以查詢當前CN節點上正在執行的作業資訊，PGXC_開頭的可查詢所有CN節點上正在執行的作業資訊，

實時TopSQL視圖為用戶記錄了作業運行時的相關資訊，比如作業下發來源、阻塞時間、執行時長、開始時間、記憶體消耗、作業下盤量、作業IO、網路、陳述句型別、陳述句的執行計劃等資訊，用戶可先通過resource_pool、nodename、username、query等資訊定位到自己需要分析的陳述句，再通過作業運行資訊定位問題，又或者用戶可通過對查詢進行篩選，篩選出當前占用資源較多的作業，

歷史TopSQL視圖記錄了作業運行結束時的資源使用情況(包括記憶體、下盤、CPU時間等)和運行狀態資訊(包括報錯、終止、例外等)以及性能告警資訊，用戶可通過對歷史陳述句運行資料的分析，篩選出執行時長較大的陳述句，看陳述句執行計劃是否有優化的空間，是否需要對表做一些analyze或者vacuum之類的操作，又比如對于記憶體報錯的情況，可分析記憶體占用高的陳述句是否合理，從執行計劃上分析是否有優化空間，

文末附TopSQL實踐：常見問題現象及對應原因，

3、TopSQL的原理決議

3.1 TopSQL原理簡介：

TopSQL的資料來源于資料庫內核，當陳述句執行時，TopSQL會實時記錄陳述句執行的相關資訊，實時TopSQL資料會保存在記憶體的臨時表中，當陳述句執行結束后，資料會轉存到對應物體表GS_WLM_SESSION_INFO中，在實際使用中，由于下發作業繁多，歷史TopSQL記錄的作業數也不斷增長，這樣會導致INFO表中的資料量逐漸龐大，為了確保數倉整體性能不受影響，支持通過TOPSQL_RETENTION_TIME來設定INFO表中資料的保存時間（單位為天），當資料存留時長超過這個時限，會對物體表GS_WLM_SESSION_INFO進行資料老化洗掉處理，

圖 3-1 TopSQL資料流通圖

如圖3-1所示，各項GUC引數決定了TopSQL生成的記錄資訊，具體的引數說明詳見第2節使用TopSQL前的檢驗，

3.2 性能分析：

對于企業用戶而言，性能問題是Top級問題，對于TopSQL功能，我們進行了性能壓測，在4TB的場景下，進行TPCC基準性能測驗，進行了2000的并發壓測，TPMC下降了約有2%，屬于可接受的范圍，

3.3 相關指標

陳述句屬性列說明：

陳述句的執行資訊屬性列,斜體代表可更換前綴/后綴式的指標，類似前綴后綴有（min_，max_，total_，average_，_skew_percent）

3.4 特殊情況說明：

TopSQL由于自身限制，存在一些記錄例外的情況，此處對8.1.3版本的TopSQL陳述句記錄情況進行說明：

1. 不記錄特殊資料定義陳述句，如：SET、RESET、SHOW、ALTER SESSION SET、SET CONSTRAINTS陳述句；
2. 記錄資料定義陳述句，例如：執行CREATE、ALTER、DROP、GRANT、REVOKE和VACUUM陳述句；
3. 記錄資料操作陳述句，例如：
1. 執行SELECT、INSERT、UPDATE和DELETE陳述句，
2. 執行explain analyze和explain performance場景，
3. 執行查詢query級別/perf級別視圖
4. ODBC下發作業，由于多陳述句原因，會記錄事務的BEGIN和end陳述句；
5. JDBC下發作業，隨機性多記錄一條JDBC的內部陳述句
6. 決議錯誤和語法報錯的例外不記錄
7. 用戶手動CANCEL作業，顯示的監控資料可能為0；
8. 當子陳述句開關打開后，只會記錄下發到DN上執行的子陳述句；
9. 游標陳述句，當游標并非從快取中讀取資料，而確實觸發陳述句下發到DN上執行的條件下，該游標陳述句會被記錄，并且會進行陳述句、執行計劃增強，但當游標從快取中讀取資料時，不進行記錄；當游標陳述句在匿名塊或者函式中使用時，當游標從DN上讀取較多資料但不完全使用時，無法記錄該游標在DN上的監控資訊，
10. JDBC執行的帶占位符陳述句，通常會補齊引數內容，但如果引數和原陳述句合起來長度超過64KB，則不記錄引數，或者如果是輕量化陳述句，直接下發到DN上執行，不記錄引數，

4、TopSQL擴展及應用

TopSQL功能是GaussDB(DWS)支持性能問題定位、陳述句劣化分析、審計回溯等重要功能的基石，在此基礎上，內核也拓展出了例外規則等一些高階用法，在日常使用中，用戶也對TopSQL提出了更高的要求，比如記錄子陳述句、記錄陳述句型別、提升算子級別陳述句監控準確性等諸多建議，為此，GaussDB（DWS）團隊會在此基礎上繼續演進，更好的服務用戶，提升用戶滿意度，

5、TopSQL實踐：常見問題定位

總結一下：

1. 因資料量變化，導致作業執行時間增加，可以分析A2/B1/D1/G1，進而確認作業查詢的資料表是否有明顯的資料量增加；
2. 因其它并發作業搶占，導致作業排隊，從而導致作業執行時間增加，可以分析A1/B1/D1，進而查看作業執行的同時期是否有大量并發作業在執行；
3. 因其它作業而產生的CPU搶占，導致作業執行時間增加，可以分析A2/D1/E1，進而查看作業執行的同時期是否有大量并發作業在執行；
4. 因其它作業而產生的IO搶占，導致作業執行時間增加，可以分析A2/F1，進而查看作業執行的同時期是否有大量并發作業在執行；
5. I1中有結果情況，可通過提示的資訊進行分析，或者進行SQL自適應診斷相關告警處理，SQL自適應診斷處理方法見：https://support.huaweicloud.com/performance-dws/dws_10_0013.html
6. 對于enqueue例外排隊的情況H1，用戶可參考：GaussDB(DWS)資源管理排隊原理與問題定位-云社區-華為云 (huaweicloud.com)，進行問題排查分析，

值得注意的是，發生資源爭搶時，可能會出現并發癥，即CPU、IO搶占，作業排隊現象都會發生，針對并發癥問題，可以逐步分析解決，比如：

第一步，調整作業執行順序，減少并發作業數量，減少阻塞時間；

第二步，定位出同時段執行的典型計算密集型、存盤密集型作業，先移動到其它時間段執行，減少對本作業的影響；

第三步，在無其他作業明顯干預的情況下，做進一步分析，

6、參考文獻：

1. GaussDB for DWS 負載管理核心技術解密二： 白話歷史資源監視-云社區-華為云 (huaweicloud.com)
2. GaussDB(DWS)資源管理排隊原理與問題定位-云社區-華為云 (huaweicloud.com)

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：再獲殊榮！華為云GaussDB喜提“科技進步一等獎”

下一篇：返回列表