PG資料庫運維中的作業系統關注點

現在PG資料庫在使用者側的應用場景日益豐富，很多國產資料庫也與PG開源專案有著很深的淵源，在使用過程中的一些基本運維規則也與PG開源資料庫十分近似。今天我們從作業系統的角度來看一看PG資料庫日常運維中需要關注的一些問題。

目前大多數使用者側的PG資料庫規模都比較小，應用系統也都不太複雜，因此大多數情況下，資料庫日常運維的難度並不大，不像Oracle這樣複雜的資料庫系統，遇到些問題還不太容易處理。在PG資料庫日常運維上，只要關注下總會話數，活躍會化，併發訪問，TOP SQL，一般也就夠用了。反而在作業系統層面，需要多加關注。

在這種情況下，作業系統的各種資源是否充足是決定資料庫執行是否穩定的十分重要的因素。CPU、記憶體、IO、儲存容量這四種資源是否充足決定了PG資料庫的執行是否穩定。網路是否存在丟包、延時過大的問題，則會影響SQL語句執行的效率。一般情況下對這些多做關注，基本上就沒有太大的問題了。

對於CPU資源，首先要觀察在業務高峰期，r佇列的數量長時間超過CPU執行緒數，甚至超過2倍。如果業務高峰期作業系統r佇列的長度經常長時間(超過10分鐘)超過CPU執行緒數，那麼說明當前CPU資源在系統高峰期存在不足的問題，如果經常超過2倍，那麼久應該準備擴容了。

對於記憶體資源，我們需要關注的是可用記憶體和交換器使用率這兩個指標，因為OS記憶體中很多記憶體是用於CACHE/BUFFER的，所以空閒記憶體的指標指示性不夠準確，使用可用記憶體可能更為準確一些，這個指標是說作業系統中還有多少真正可用於分配的記憶體。

MemAvailable指標的含義是當前記憶體中還可用於分配的所有記憶體的總和。如果這個值比較小了，說明當前的OS中可以用於分配的記憶體過小，系統存在隱患。

另外一個需要關注的指標是SWAP使用率，有些PG的使用攻略中甚至建議大家關閉SWAP，從而避免因為SWAP帶來的效能不穩定。這種建議實際上是因為無法控制SWAP，以及控制SWAP帶來的負面影響而採用的一種極端的措施。在當前的LINUX核心下，SWAP產生的原因十分複雜，因此乾脆透過關閉SWAP來避開SWAP了。這種做法實際上是不可取的，因為你都沒辦法搞明白SWAP產生的原因，那麼如果關閉了SWAP，一旦SWAP需要產生的時候，那麼OS會採取更為極端的方式來對待，那就是OOM KILLER程式殺掉某些程式。如果正好Postmaster正好是那個倒黴蛋，那麼就不是PG效能受到影響了，而是PG庫就宕了。目前我們常用的Linux 7、8核心的swap演算法已經都比較完善了，大多數情況下，SWAP不會對影響PG資料庫效能比較嚴重的匿名塊做SWAP，而會盡可能交換CACHE/BUFFER，因此只要基礎的LINUX VM引數設定的比較合理，就無需懼怕SWAP的產生。而當系統的SWAP使用率一直居高不下(比如超過90%)，才需要重點關注。

IO延時也是我們運維PG資料庫時需要關注的，因為PG資料庫的DOUBLE BUFFER特性，實際上IO延時對PG資料庫的影響並不一定像對Oracle那麼直接。有時候IO延時挺高了，但是PG資料庫的效能似乎受到的影響還不算大。不過不管怎麼樣，IO延時低於20毫秒是運維PG資料庫的一個基本底線。過高的IO延時肯定會對PG資料庫長期穩定執行存在隱患(當PG資料庫負載較小的時候，這種影響還不一定會體現出來)。在一個相對穩定的執行環境中，如果IO總量變化不大的時候，IO延時應該也是相對穩定的，如果IO總量不變的情況下，IO延時越來越長，那麼說明底層IO裝置或者後端儲存存在問題，我們需要儘早關注，以免出現大問題。儲存子系統的問題，對於資料庫來說往往是致命的。

另外一個容易受到忽視，但是一旦出現問題就容易引發大問題的是作業系統層面的程式的狀態。如果程式中出現了幾類特殊的非正常程式，那麼我們就需要加以關注了。如果這些程式屬於postgres使用者，那麼就需要額外關注了。一般程式狀態有r(執行或可允許),S(可中斷的休眠狀態)，這兩種狀態的程式都是正常的。而處於D(不可中斷的休眠狀態)的程式往往是在等待IO完成等核心呼叫，這個狀態如果短時存在，並且很快消失了，那很可能是IO效能存在問題，並不危險，如果系統中經常有大量程式處於D狀態，那麼就需要關注了，是不是OS在IO層面存在問題了。而且隨著D狀態的程式數量愈來愈多，OS的風險也越來越大，伺服器從長遠看，存在比較大的風險。另外T狀態的程式也應該是一個臨時狀態，等程式歸還資源後應該就立即被關閉了，如果有程式長期處於T狀態，那麼系統肯定存在某些風險，需要關注。同理是Z狀態的程式(僵死)。關注OS中的這些非正常狀態的程式的數量變化以及某個非正常狀態的程式是否長期處於該狀態，是我們PG DBA運維資料庫系統時應該關注的。

OS層面需要關注的內容還有很多，比如透過lsof看看開啟檔案控制程式碼的總數是否存在不合理的增長，ulimit引數的限制是否會出現風險，OS程式數量是否異常，dmesg和messages是否存在異常報錯等，都是PG DBA需要經常去檢查檢查的。這些檢查十分瑣碎，有些也過於專業。因此PG DBA也需要構建一些工具，定期自動的去做巡檢，從而確保資料庫所執行的OS環境是安全的。今天時間關係，我們就先聊這麼多吧。在12月30號晚上的分享中，我會給大家介紹一些更細的內容。