opengauss ASP的幾點優化建議

本周五的openGauss開發者大會上我分享的內容里有幾條對openGauss可觀測性優化提升的建議，原本也想會后和研發的朋友一起探討一下這幾個問題。不過因為北京健康寶彈窗，很大可能性是無法線下參會了，今天我利用公眾號這個平臺先發一篇文章，具體的內容在周五下午的生態工具分論壇的最后一個演講中也會提及。

關于數據庫可觀測性的重要性不用再多說了，各個國產數據庫也在努力提供可觀測性的數據給廣大用戶，只不過從DBA的角度來說，這些國產數據庫廠商提供的可觀測性數據的質量都不夠高，不足以用于日常的運維分析、性能優化和故障定位。從一個老DBA的角度，今天我提幾個openGauss的可觀測性方面的優化建議，也算是給無法親臨現場的openGauss開發者大會添幾根柴吧。

第一個優化建議是提給ASP的，ASP應該是openGauss開發人員引以為傲的功能之一了，確實ASP也算是我見到的國產數據庫里第一個類似Oracle ASH的實現。ASP為運維人員提供了相當好的歷史問題分析和性能分析的接口，我第一次看到這個功能的存在的時候也是比較興奮的，不過興奮之余，我又有點失望了，因為高斯的ASP里沒有等待時間。

GS_ASP是持久化的數據，在內存中是DBE_PERF.LOCAL_ACTIVE_SESSION,其結構和GS_ASP基本一致。缺乏等待時間和ASP數據的采集位置有關，如果只在等待開始時候記錄就很難記錄到等待時長了。缺乏等待時長，在分析等待事件的時候，就不知道某個等待事件是不是處于正常狀態。從高斯提供的另外一個接口看，openGauss是能夠采集等待時長的。

在這個接口中，我們可以看到平均等待時長，最大，最小等待時長等數據，說明高斯是有能力提供等待時長這個數據的，因此在GS_ASP/LOCAL_ACTIVE_SESSION中提供這個數據也是有可能的。我們期待能夠看到這個改進。只不過這種改進看似很小，對于內核代碼來說是巨大的考驗，不能為了增加這個可觀測性數據而影響了高斯的并發性能。

另外一點就是針對ASP數據的篩選問題，目前ASP數據產生的太多了，很多數據中包含的信息對運維分析幫助不大（一部分EVENT為NULL，也沒有持有鎖，也沒有阻塞別人或者被別人阻塞的活躍會化數據，可能是價值較小的，可以通過算法進行排除），在持久化的時候，應該把這部分數據盡可能的排除掉，這樣會讓數據更有效。目前默認的持久化比例是10:1，雖然這個參數可以調整，不過我們測試的情況來看，1:1保存還是有一定的資源開銷的，保存的記錄數量也十分龐大。這種采樣可能會丟失掉大量的有效數據，如果能夠通過高質量的篩選去除不重要的數據，剩下的全量保存，那樣就更好了。

ASP的持久化保存，最佳的方式是文件方式，目前高斯支持文件方式保存，不過不是默認的。文件保存的開銷最小，不過訪問接口有點麻煩，因此選擇文件保存作為默認方式后，還應該提供兩個功能，一個是保存時長的問題，目前表的保存方式是可以設定保存時長的，這個參數應該也能夠影響文件保存的時長，能夠自動刪除歷史數據。同時高斯也應該提供對于文件保存的ASP數據的視圖訪問方式（類似于外部表的實現方式），讓運維人員可以通過簡單的SQL語句來訪問該數據。

為了更好的進行ASP分析，DBE_PERF.WAIT_EVENTS也需要做一定的優化，創建一個DBE_PERF.WAIT_EVENTS_HISTGRAM接口，用于存儲等待事件的柱狀圖信息。WAIT_EVENTS_HISTGRAM里包含了多種等待時長的等待次數的統計信息，這樣運維人員根據柱狀圖信息，就更容易看出來某個等大事件在系統總發生了什么變化，可能存在什么問題了。只有簡單的平均值最大值最小值無法給DBA分析提供足夠的數據，如果能夠在內存中存放最近半小時的柱狀圖信息，并且把歷史的祝張圖信息持久化到GS_WAIT_EVENTS_HISTGRAM表中，那么一旦DBA需要分析系統出現過的問題，或者做系統運行的趨勢分析，就更加容易了。

除此之外，針對ASP數據，實際上也只能給運維專家來看，普通的DBA很難看得懂ASP數據。因此也可以模仿Oracle ASH報告的內容，提供一個產生ASP REPORT的接口，讓技術稍微潮一點的小白也能做點ASP分析，肯定是一件十分有價值的事情。有ASH報告的模板在那放著，要實現一個高斯的ASP報告難度也不大。

最后，也是最重要的一點，就是高斯的文檔里能不能出一份等待事件參考手冊。Oracle的每個等待事件，基本上都能在MOS上找到一份闡述性文檔，以及多份與之相關的文檔，BUG報告，優化建議等。如果openGauss社區也能維護一本這種不斷完善的參考手冊，那么對于運維人員來說絕對是個福音了。