?現(xiàn)在PG數(shù)據(jù)庫在用戶側(cè)的應(yīng)用場景日益豐富，很多國產(chǎn)數(shù)據(jù)庫也與PG開源項目有著很深的淵源，在使用過程中的一些基本運維規(guī)則也與PG開源數(shù)據(jù)庫十分近似。今天我們從操作系統(tǒng)的角度來看一看PG數(shù)據(jù)庫日常運維中需要關(guān)注的一些問題。

目前大多數(shù)用戶側(cè)的PG數(shù)據(jù)庫規(guī)模都比較小，應(yīng)用系統(tǒng)也都不太復(fù)雜，因此大多數(shù)情況下，數(shù)據(jù)庫日常運維的難度并不大，不像Oracle這樣復(fù)雜的數(shù)據(jù)庫系統(tǒng)，遇到些問題還不太容易處理。在PG數(shù)據(jù)庫日常運維上，只要關(guān)注下總會話數(shù)，活躍會化，并發(fā)訪問，TOP SQL，一般也就夠用了。反而在操作系統(tǒng)層面，需要多加關(guān)注。

在這種情況下，操作系統(tǒng)的各種資源是否充足是決定數(shù)據(jù)庫運行是否穩(wěn)定的十分重要的因素。CPU、內(nèi)存、IO、存儲容量這四種資源是否充足決定了PG數(shù)據(jù)庫的運行是否穩(wěn)定。網(wǎng)絡(luò)是否存在丟包、延時過大的問題，則會影響SQL語句執(zhí)行的效率。一般情況下對這些多做關(guān)注，基本上就沒有太大的問題了。

對于CPU資源，首先要觀察在業(yè)務(wù)高峰期，r隊列的數(shù)量長時間超過CPU線程數(shù)，甚至超過2倍。如果業(yè)務(wù)高峰期操作系統(tǒng)r隊列的長度經(jīng)常長時間（超過10分鐘）超過CPU線程數(shù)，那么說明當(dāng)前CPU資源在系統(tǒng)高峰期存在不足的問題，如果經(jīng)常超過2倍，那么久應(yīng)該準(zhǔn)備擴容了。

對于內(nèi)存資源，我們需要關(guān)注的是可用內(nèi)存和交換器使用率這兩個指標(biāo)，因為OS內(nèi)存中很多內(nèi)存是用于CACHE/BUFFER的，所以空閑內(nèi)存的指標(biāo)指示性不夠準(zhǔn)確，使用可用內(nèi)存可能更為準(zhǔn)確一些，這個指標(biāo)是說操作系統(tǒng)中還有多少真正可用于分配的內(nèi)存。

MemAvailable指標(biāo)的含義是當(dāng)前內(nèi)存中還可用于分配的所有內(nèi)存的總和。如果這個值比較小了，說明當(dāng)前的OS中可以用于分配的內(nèi)存過小，系統(tǒng)存在隱患。

另外一個需要關(guān)注的指標(biāo)是SWAP使用率，有些PG的使用攻略中甚至建議大家關(guān)閉SWAP，從而避免因為SWAP帶來的性能不穩(wěn)定。這種建議實際上是因為無法控制SWAP，以及控制SWAP帶來的負(fù)面影響而采用的一種極端的措施。在當(dāng)前的LINUX內(nèi)核下，SWAP產(chǎn)生的原因十分復(fù)雜，因此干脆通過關(guān)閉SWAP來避開SWAP了。這種做法實際上是不可取的，因為你都沒辦法搞明白SWAP產(chǎn)生的原因，那么如果關(guān)閉了SWAP，一旦SWAP需要產(chǎn)生的時候，那么OS會采取更為極端的方式來對待，那就是OOM KILLER進程殺掉某些進程。如果正好Postmaster正好是那個倒霉蛋，那么就不是PG性能受到影響了，而是PG庫就宕了。目前我們常用的Linux 7、8核心的swap算法已經(jīng)都比較完善了，大多數(shù)情況下，SWAP不會對影響PG數(shù)據(jù)庫性能比較嚴(yán)重的匿名塊做SWAP，而會盡可能交換CACHE/BUFFER，因此只要基礎(chǔ)的LINUX VM參數(shù)設(shè)置的比較合理，就無需懼怕SWAP的產(chǎn)生。而當(dāng)系統(tǒng)的SWAP使用率一直居高不下（比如超過90%），才需要重點關(guān)注。

IO延時也是我們運維PG數(shù)據(jù)庫時需要關(guān)注的，因為PG數(shù)據(jù)庫的DOUBLE BUFFER特性，實際上IO延時對PG數(shù)據(jù)庫的影響并不一定像對Oracle那么直接。有時候IO延時挺高了，但是PG數(shù)據(jù)庫的性能似乎受到的影響還不算大。不過不管怎么樣，IO延時低于20毫秒是運維PG數(shù)據(jù)庫的一個基本底線。過高的IO延時肯定會對PG數(shù)據(jù)庫長期穩(wěn)定運行存在隱患（當(dāng)PG數(shù)據(jù)庫負(fù)載較小的時候，這種影響還不一定會體現(xiàn)出來）。在一個相對穩(wěn)定的運行環(huán)境中，如果IO總量變化不大的時候，IO延時應(yīng)該也是相對穩(wěn)定的，如果IO總量不變的情況下，IO延時越來越長，那么說明底層IO設(shè)備或者后端存儲存在問題，我們需要盡早關(guān)注，以免出現(xiàn)大問題。存儲子系統(tǒng)的問題，對于數(shù)據(jù)庫來說往往是致命的。

另外一個容易受到忽視，但是一旦出現(xiàn)問題就容易引發(fā)大問題的是操作系統(tǒng)層面的進程的狀態(tài)。如果進程中出現(xiàn)了幾類特殊的非正常進程，那么我們就需要加以關(guān)注了。如果這些進程屬于postgres用戶，那么就需要額外關(guān)注了。一般進程狀態(tài)有r(運行或可允許),S(可中斷的休眠狀態(tài))，這兩種狀態(tài)的進程都是正常的。而處于D(不可中斷的休眠狀態(tài))的進程往往是在等待IO完成等內(nèi)核調(diào)用，這個狀態(tài)如果短時存在，并且很快消失了，那很可能是IO性能存在問題，并不危險，如果系統(tǒng)中經(jīng)常有大量進程處于D狀態(tài)，那么就需要關(guān)注了，是不是OS在IO層面存在問題了。而且隨著D狀態(tài)的進程數(shù)量愈來愈多，OS的風(fēng)險也越來越大，服務(wù)器從長遠看，存在比較大的風(fēng)險。另外T狀態(tài)的進程也應(yīng)該是一個臨時狀態(tài)，等進程歸還資源后應(yīng)該就立即被關(guān)閉了，如果有進程長期處于T狀態(tài)，那么系統(tǒng)肯定存在某些風(fēng)險，需要關(guān)注。同理是Z狀態(tài)的進程（僵死）。關(guān)注OS中的這些非正常狀態(tài)的進程的數(shù)量變化以及某個非正常狀態(tài)的進程是否長期處于該狀態(tài)，是我們PG DBA運維數(shù)據(jù)庫系統(tǒng)時應(yīng)該關(guān)注的。

OS層面需要關(guān)注的內(nèi)容還有很多，比如通過lsof看看打開文件句柄的總數(shù)是否存在不合理的增長，ulimit參數(shù)的限制是否會出現(xiàn)風(fēng)險，OS進程數(shù)量是否異常，dmesg和messages是否存在異常報錯等，都是PG DBA需要經(jīng)常去檢查檢查的。這些檢查十分瑣碎，有些也過于專業(yè)。因此PG DBA也需要構(gòu)建一些工具，定期自動的去做巡檢，從而確保數(shù)據(jù)庫所運行的OS環(huán)境是安全的。今天時間關(guān)系，我們就先聊這么多吧。在12月30號晚上的分享中，我會給大家介紹一些更細(xì)的內(nèi)容。?