PostgreSQL數據庫是近年來熱度上升最快的關系型數據庫之一，近年來大量國內企業都在把系統向PostgreSQL上遷移。目前熱度較高的國產數據庫中也有一大半的廠商選擇了PostgreSQL開源項目作為數據庫產品的研發基礎。不過PostgreSQL的運維一直是個難點，與Mysql相比，PostgreSQL過于復雜，運維難度遠大于Mysql。而與Mysql相比，熟悉PostgreSQL運維與優化的DBA數量又遠遠不及。再加上開源數據庫的文檔資料相比Oracle等商用數據庫來說更是差距甚大，如何做好PostgreSQL數據庫的運維就成為很多企業面臨的大問題。 在2020年的第十屆中國PG用戶大會上，我分享了一個主題-《基于知識圖譜的PostgreSQL深度分析》，當時正好是基于PG的知識圖譜1.0剛剛具備雛形的時候，正在實驗性的用于D-SMART產品中，對PG等數據庫進行輔助診斷。

當時我們采用在生產系統中采樣，并進行專家標注的方法構建分析中最為核心的異常檢測算法，結合知識圖譜定義的診斷路徑，找出與某個故障現象相關的指標集，然后通過異常檢測發現其中存在問題的子集，最后通過收斂算法，找到問題的根因。 在那個演講中，我舉了一個實際的案例，在一個電力客戶中有一套PG數據庫，現場DBA對PG運維完全無感，因此這套系統一直是在盲跑，到底有沒有問題，只有老天知道，只要不宕機就啊彌陀佛了?？蛻舴答佅到y慢也沒有任何辦法去做分析，因為運維團隊里沒有任何針對PG進行優化的知識。 正好客戶和我們一起啟動了一個智能化運維的課題，于是我們就針對這套數據庫進行了一些智能診斷的嘗試。在D-SMART 1.9中我們提供了一個智能診斷工具，利用這套知識庫可以進行初步的分析，將問題收斂到了幾個方面，運維人員根據這些方面的分析結論，結合智能化工具推薦的診斷工具，手動點擊這些工具，最終定位了問題。這種智能化輔助的手段可以減輕DBA的工作負擔，提高問題定位的正確性。不過也只是能夠起到一定的輔助作用。 當時我們分享的這個案例只是一個實驗性的案例，我們采用的異常檢測算法是依賴于專家人工標注的。

通過離線的數據采集，經過無監督學習(實際上就是暴力計算)找到一些疑似故障點，然后對這些數據進行一定的人工標注，再通過半監督學習構建模型，用于生產系統中的異常檢測。為什么要采用這種迂回的方法來構建異常檢測模型呢？這是因為暴力計算需要很高的算力，如果用于實時監控，對服務器CPU資源消耗過大，需要一個龐大的集群才能支撐較大規模的數據庫運維場景。 這種方法雖然在實驗室中獲得了一定的效果，但是在實際生產環境中我們遇到了一個巨大的問題，那就是這樣構建起來的模型并不通用，換了一個客戶，甚至在一個客戶的多個不同的數據庫或多個不同業務類型的應用系統中模型都不通用。對于一個具有數百個甚至上千個數據庫實例的用戶來說，都采用如此高成本的模型構建方法是完全行不通的。后來我們又嘗試了一系列基于時間序列的無監督算法，比如HTM/LSTM，以及隨機森林等方法，最后獲得的效果都不理想。 基于上面遇到的問題，在構建2.0版本的知識庫的時候，我們放棄了以前的一些設計，針對異常檢測，需要找到一種計算量較小的，不依賴于專家標注的算法。于是我們想到了模仿Oracle的統計信息，以一定周期為單位(比如一周，半個月)，滾動更新統計數據，采集指標的數據進行采樣，構建常規運行的數據模型，然后根據這些數據模型，建立算力要求較低的算法，用于生產環境的指標異常檢測。 同時針對知識庫的更新也在繼續進行。從去年1.0版本的數千個頂點，兩萬多個關系變為5萬個頂點，十幾萬個關系。

在知識庫構建的過程中，1.0版本主要解決了從某個故障場景的診斷路徑自動發散，通過發散后的路徑來尋找各種問題的可能性。1.0版本并沒有解決好問題的收斂，雖然智能診斷可以不斷地發散，讓DBA抓住所有的蛛絲馬跡，但是沒辦法對問題進行收斂歸類。從而較為準確的定位故障點，有時候甚至會出現大量的誤判，把一些與這個故障無關的因素分析了出來。這是因為數據庫系統是一個十分復雜的系統，當某類問題出現的時候，系統中還存在很多其他方面的問題，這些都可能對智能化分析產生嚴重的干擾。在數據庫專家的輔助下，這些干擾可以比較容易的被裁剪，但是智能分析算法并沒有人類的這種智慧，只是一種算法智能，是無法解決這些問題的。因此2.0版本的知識庫中重點對診斷路徑的收斂做了優化，最后形成比較規范的故障結論。 實際上，智能化診斷是一種算力與算法的診斷，而并不完全是一個真正的人工智能，我們更喜歡稱之為“知識自動化”，是一種基于各種傳感技術與算力的自動化駕駛。 首先是通過各種異常發現的算法與規則引擎，找出異常點，并歸納為某個異常場景。然后通過知識圖譜發散思維，合理的擴散診斷路徑。第三步是根據診斷路徑找到關聯指標，形成待分析的指標集。第四步是通過異常檢測算法對這個指標集進行檢測分析，找出可能的問題路徑。最后對問題路徑進行收斂，獲得分析結果。 下面是D-SMART 2.0的一個診斷案例，我們在進行模擬壓測時，D-SMART出現了一個告警，含義是shared buffers中的臟塊寫盤的狀態出現了異常，backend進程承擔了過多的臟塊寫出的工作。

比如上面的這個故障場景，在系統負載比較高的時候，經常會出現backend回寫共享緩存的比例過高的問題，這會影響應用的性能，對于一些性能敏感的應用影響較大。針對這個告警，D-SMART提供了一個智能化分析工具和幾條標準化的診斷路徑。上面是“智能指標分析”工具顯示的相關指標情況，在后面，該工具直接給出了診斷結論： 診斷結論還是通俗易懂的，懂一些PostgreSQL運維的人都可以獲得如下的信息，首先這個問題出現的原因是系統并發量太大，其次數據庫的配置有可優化的地方。另外系統中存在TOP SQL，IO的吞吐量也有點大。 事實是否如此呢？首先并發量大這一點十肯定的，因為出現告警的時間段正好在做壓測。系統配置是不是有問題，我們可以直接通過工具去驗證。目前2.0的知識庫還有一個地方不夠完善，那就是針對finding的確認，在2.1版本中，知識庫里會帶有診斷結果確認的知識，當然這些知識是通過關聯相關診斷知識點來實現的。升級到2.1版本的知識庫后，在每個發現后面會直接輸出自動確認的結果。 圖片 對BGWRITER相關參數的分析，提出的建議是不調整相關參數，而去加大shared buffers。從shared buffers的命中率看，確實在問題發生的時間段內的命中率較低。

這也是PostgreSQL數據庫常見的問題，當shared buffers不足的時候，大量的數據塊需要寫出，此時backend就被迫承擔了大量的bgwriter的工作了。對于大型的PostgreSQL數據庫，要盡可能減少這種情況的出現。

上面的診斷結果和智能診斷的finding中DB CACHE配置不合理是吻合的，根據上面的建議，我們把shared buffers調整為15GB，然后再加載類似的負載。再看看剛才的問題是否緩解了。

從上面的這個數據可以看出，調整shared buffers之后，backend進程寫出共享緩存的比例合理多了。和今天上午同樣壓測的情況相比，也要低了很多。我們再來看shared buffers的命中率情況：

Shared buffers的命中率也沒有再出現上午的抖動情況。從壓測工具上來看，tpmc也穩定在60多萬，比上午增加了15%左右，而且tpmc也不像上午壓測那樣抖動了。從這個例子來看，知識庫2.0很好的幫助DBA完成了一次較為復雜的診斷。 知識庫2.0版本在分析能力上必1.0版本有了較大的提升，代價是在D-SMART服務器上需要消耗大量的CPU資源去對已有的監控數據做采樣分析，從而獲得較為準確的數據，用于指標的異常檢測。和傳統的監控系統相比，智能化運維工具需要更高的算力來做支撐。隨著工具能力的不斷提升，D-SMART從一個只需要跑在一臺配置很低的虛擬機上，已經變成了一個算力吞金獸了。

總結

以上是生活随笔為你收集整理的postgresql日常运维：Postgresql运维的自动驾驶的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。