?現(xiàn)在基于PG或者脫胎于PG的國產(chǎn)數(shù)據(jù)庫越來越多，再加上PG社區(qū)版用戶也在快速增長，因此多學點PG的知識對于DBA今后的轉(zhuǎn)型來說，還是挺有用的，因此這幾天我們多討論一些PG相關(guān)的問題。昨天我們討論了PG IO優(yōu)化方面的問題，今天我們就來討論一個核CPU有關(guān)的問題。今天的議題是，如果PG數(shù)據(jù)庫服務(wù)器的CPU使用率突然升高，我們應(yīng)該從哪幾個方面去分析。

如果遇到數(shù)據(jù)庫服務(wù)器CPU使用率突然大幅增高或者過高的問題，不論是哪種數(shù)據(jù)庫，我們都要首先查看一下操作系統(tǒng)上有沒有非數(shù)據(jù)庫的進程使用了過高的CPU資源，這個使用TOP工具就可以實現(xiàn)了，不要因為SWAP、大規(guī)模CACHE DROP等操作引發(fā)的CPU使用率突增讓數(shù)據(jù)庫來背鍋了，搞的你分析了一大圈，發(fā)現(xiàn)完全和數(shù)據(jù)庫無關(guān)。幾年前我遇到過一個案例，一個用戶讓我?guī)椭治鏊麄兊腃PU怎么突然100%了，我也是沒注意這些問題，直接在數(shù)據(jù)庫里找問題，最后分析了一大圈，發(fā)現(xiàn)負載啥的都和前一天沒啥區(qū)別，就是CPU使用率多了30%。后來實在沒招了，用TOP看了一下，發(fā)現(xiàn)了一個異常的進程，居然在做科學計算，這個進程正好消耗了30%多的CPU資源。最后客戶那邊確認了一下，十分不好意思的說，是一個幾年前設(shè)置的一個crontab任務(wù)忘了關(guān)閉了，才導(dǎo)致了今天的問題。幾年前，他們搞數(shù)據(jù)庫合庫，只要CPU使用率在一個月中沒有一天業(yè)務(wù)高峰期超過35%的數(shù)據(jù)庫，就必須合并到其他數(shù)據(jù)庫中，從而節(jié)約資源。他們干了幾套系統(tǒng)后覺得太辛苦了，部門領(lǐng)導(dǎo)就想了個招，在月底業(yè)務(wù)高峰期的時候，讓一個科學計算的任務(wù)跑上幾個小時，讓符合合并的數(shù)據(jù)庫變少一點，大家也少干點活。沒想到這臺服務(wù)器上的任務(wù)忘了關(guān)了，而這些年這套系統(tǒng)的數(shù)據(jù)量越來越大，負載也越來越高了，沒想到這個月底業(yè)務(wù)很忙，居然把CPU跑爆掉了。

另外如果在一臺物理機上跑多個數(shù)據(jù)庫實例，我們就不能只看一個數(shù)據(jù)庫的情況了，而是要看多個數(shù)據(jù)庫的總體負載。

除此之外，如果排除了這些問題，單單來討論PG數(shù)據(jù)庫，如果真的是PG數(shù)據(jù)庫引發(fā)了CPU突然增加，我們應(yīng)該如何去分析呢？今天我簡單的羅列了一些常用場景，遇到問題的時候，DBA可以一條條的進行排除。

首先，也是可能性最大的方面，出現(xiàn)大查詢或者較高并發(fā)量的SQL執(zhí)行計劃變壞：如果數(shù)據(jù)庫中的某個查詢或某組查詢的復(fù)雜度增加，則可能導(dǎo)致CPU使用率的增加；一條常見SQL的執(zhí)行計劃錯誤也會導(dǎo)致執(zhí)行開銷增加，雖然單條SQL的延時仍然在業(yè)務(wù)能夠忍受的范圍內(nèi)，但是總體CPU消耗會大幅增大，如果CPU資源出現(xiàn)瓶頸，那么系統(tǒng)整體性能都會嚴重下降。

第二，出現(xiàn)嚴重的資源競爭：如果多個連接或會話同時請求大量的數(shù)據(jù)，則可能會產(chǎn)生資源競爭，甚至引發(fā)spinlock等自旋鎖爭用，從而導(dǎo)致CPU使用率的增加，分析這方面的原因通過PG的等待事件進行分析是比較有效的。

第三，索引缺失導(dǎo)致的SQL執(zhí)行計劃不夠優(yōu)化：如果數(shù)據(jù)庫表缺少索引，則查詢操作將需要掃描整個表，從而導(dǎo)致CPU使用率的增加。

第四，磁盤IO瓶頸：如果數(shù)據(jù)庫的磁盤IO不能滿足需求，則可能導(dǎo)致CPU使用率的增加。這一點可能會讓朋友們感到詫異，IO瓶頸的時候，會話不都在等待IO嗎？怎么會引發(fā)CPU的問題呢？PostgreSQL 使用同步阻塞 IO（Buffered IO），同步阻塞 IO 意味著在完成 IO 操作之前，PostgreSQL 會阻塞等待 IO 操作的完成。當數(shù)據(jù)庫服務(wù)器需要讀寫磁盤數(shù)據(jù)時，它會阻塞其他操作，直到 IO 操作完成。在這種情況下，IO延時會比平時高很多，CPU使用率中的IOWAIT的比例也會比較高。

第五，數(shù)據(jù)庫維護任務(wù)：如果數(shù)據(jù)庫正在進行大型的維護任務(wù)（例如VACUUM，ANALYZE等），則可能導(dǎo)致CPU使用率的增加。

第六，緩沖污染：這種情況出現(xiàn)幾率較低，而且出現(xiàn)后也很難被發(fā)現(xiàn)。當緩存中的數(shù)據(jù)大多數(shù)是很少使用的數(shù)據(jù)時，就會出現(xiàn)緩存污染，導(dǎo)致頻繁的緩存未命中，導(dǎo)致 CPU 利用率增加。當緩存污染發(fā)生時，CPU 會花更多的時間從存儲中讀取數(shù)據(jù)，而花更少的時間從緩存中執(zhí)行指令。 這會導(dǎo)致整體系統(tǒng)性能下降和 CPU 使用率增加。對于PG這種shared_buffers配置占OS比例較低，采用DOUBLE BUFFER機制的數(shù)據(jù)庫系統(tǒng)，出現(xiàn)緩沖污染的幾率遠大于Oracle等數(shù)據(jù)庫。緩沖污染一旦產(chǎn)生，在SQL執(zhí)行計劃不發(fā)生變化的情況下，也會產(chǎn)生較為嚴重的性能下降，因此需要避免。對于經(jīng)常出現(xiàn)類似問題的數(shù)據(jù)庫，可以通過使用各種預(yù)熱插件來不斷預(yù)熱熱數(shù)據(jù)，從而防止緩沖污染。

第七，某張經(jīng)常全表掃碼的小表因為膨脹而突然變大：這種情況出現(xiàn)概率較低，不過也比較容易出現(xiàn)，如果某張表關(guān)閉了VACUUM并且常有UPDATE操作，那么經(jīng)過一段時間積累，可能引發(fā)性能問題。

導(dǎo)致CPU使用率突然增高的可能性還有很多，不過對于PG數(shù)據(jù)庫來說，大部分此類問題都是大并發(fā)SQL或者SQL執(zhí)行計劃變壞引發(fā)，加強SQL問題的監(jiān)控一般來說能解決大多數(shù)PG的CPU問題。今天時間有限，僅僅討論了一下常見的故障場景。不斷積累這方面的知識庫是企業(yè)和DBA應(yīng)該做的事情，如果能夠通過社區(qū)共同積累此類問題，那就會事半功倍。也希望大家有興趣加入我們的DBAIOPS社區(qū)，共同來做這項工作。這項工作的成果會發(fā)布在D-SMART社區(qū)版中，我們也會定期通過文章匯報匯總的情況。?