我是從C程序員轉(zhuǎn)DBA的，所以遇到數(shù)據(jù)庫的一些問題，我總是喜歡從一個碼農(nóng)的角度去發(fā)出靈魂拷問：為什么會這樣？為什么要這樣？這么做有啥必要？經(jīng)過二十多年時間，Oracle的一些犄角旮旯的問題都被我理解和接受了。剛剛轉(zhuǎn)向PG數(shù)據(jù)庫的學(xué)習(xí)的時候，對PG這個簡單但是龐大的數(shù)據(jù)庫系統(tǒng)的一些行為十分不解。今天我們就來聊聊我對BGWRITER的一些思考。

PG的后臺寫入器（Background Writer, bgwriter）負(fù)責(zé)將臟頁（即被修改但尚未寫入磁盤的數(shù)據(jù)頁）從共享緩沖區(qū)寫回到磁盤，從而減少直接由前端查詢進(jìn)程執(zhí)行寫操作的需求,BGWRITER對數(shù)據(jù)庫的性能優(yōu)化具有重要作用。對Oracle的dbwr的算法比較了解的DBA剛開始可能很難理解PG的刷臟機(jī)制。因?yàn)槌薆GWriter之外，Checkpoint、Backend都有刷臟的行為。Checkpoint刷臟比較容易理解，因?yàn)樵缙贠racle的CKPT也是有刷臟行為的。需要Checkpoint的時候，如果發(fā)現(xiàn)某些需要寫入的臟塊暫時還沒有寫入，并且這些數(shù)據(jù)塊當(dāng)前處于可以寫入的狀態(tài)，這種情況下CKPT順手就做了。后來為了解決高并發(fā)環(huán)境下的閂鎖開銷問題，O記才讓CKPT不再刷臟，提高Checkpoint推進(jìn)的速度。

PG和O記最大的不同是Backend也是有刷臟行為的，這個設(shè)計(jì)剛開始的時候讓我感到十分不解。BGWriter和Checkpoint都可以刷臟對于閂鎖爭用來說問題還不是太大，頂多是兩個會話協(xié)同好就行了，而Backend的數(shù)量可能很龐大，如果同時又刷臟需求的話，協(xié)調(diào)好共享池相關(guān)數(shù)據(jù)結(jié)構(gòu)的LWLOCK成本就低不了。

BGWriter在掃描共享緩沖區(qū)時，采用了一種基于LRU（Least Recently Used，最近最少使用）算法的啟發(fā)式方法來選擇要刷新的頁面。具體來說BGWriter會優(yōu)先對最近最少被使用的臟頁進(jìn)行回寫，即這些頁面在未來短時間內(nèi)不太可能被再次訪問，因此將它們寫回到磁盤可以釋放內(nèi)存而不大影響性能。如果一個頁面當(dāng)前正被其他后端進(jìn)程讀取或修改，那么BGWriter會跳過該頁面。除此之外，BGWriter的行為受bgwriter_lru_maxpages和bgwriter_lru_multiplier等參數(shù)的影響。每次循環(huán)中，BGWriter嘗試寫的最大臟頁數(shù)由bgwriter_lru_maxpages指定，而實(shí)際嘗試寫的頁數(shù)則根據(jù)系統(tǒng)近期需求動態(tài)調(diào)整，這取決于bgwriter_lru_multiplier。如果當(dāng)前循環(huán)中已達(dá)到設(shè)定的最大寫入頁數(shù)限制，則即使還有未處理的臟頁，也會暫時跳過。

bgwriter_lru_maxpages參數(shù)比較容易理解，就是bgwriter一個批處理任務(wù)中刷臟的最大臟頁數(shù)量，刷夠了這些頁，bgwriter就結(jié)束這次任務(wù)，進(jìn)入休眠。bgwriter_lru_multiplier 是一個用于調(diào)整PostgreSQL后臺寫入器（Background Writer, BGWriter）行為的重要參數(shù)。它決定了BGWriter嘗試預(yù)測需要刷新多少頁面到磁盤的積極程度，基于最近幾次前臺請求所需頁面數(shù)量進(jìn)行計(jì)算。BGWriter會監(jiān)控最近幾次前臺請求所需的新緩沖區(qū)頁面數(shù)，并將這個數(shù)值乘以 bgwriter_lru_multiplier 來決定下一次循環(huán)應(yīng)該嘗試刷新多少個臟頁回到磁盤。假設(shè)最近幾次前臺請求所需的平均新緩沖區(qū)頁面數(shù)為N，則在下一個周期內(nèi)，BGWriter將會嘗試刷新 N * bgwriter_lru_multiplier 個臟頁。這意味著如果 bgwriter_lru_multiplier 設(shè)置得較高，BGWriter就會更積極地嘗試將更多的臟頁寫回磁盤；反之，如果設(shè)置得較低，則BGWriter的行為會更加保守。

與BGWriter相對保守的刷臟策略相比，Checkpoint是一種強(qiáng)制刷臟機(jī)制。Checkpoint的主要目的是縮短崩潰恢復(fù)時間，因?yàn)樗薅嘶謴?fù)過程中需要回放的WAL（Write-Ahead Logging）日志的范圍。Checkpoint可以由多種條件觸發(fā)，包括達(dá)到checkpoint_timeout設(shè)定的時間間隔（默認(rèn)為5分鐘），或WAL文件使用量達(dá)到了max_wal_size。此外，也可以手動觸發(fā)Checkpoint。當(dāng)Checkpoint開始時，PostgreSQL會強(qiáng)制將所有臟數(shù)據(jù)頁寫回到磁盤。這包括但不限于共享緩沖區(qū)中的數(shù)據(jù)頁。為了保證一致性，Checkpoint期間不允許新的事務(wù)提交（盡管允許讀取和正在進(jìn)行的事務(wù)繼續(xù)）。整個過程包括了標(biāo)記一個檢查點(diǎn)記錄到WAL日志中，并更新控制文件以反映最新的檢查點(diǎn)信息。與BGWriter不同，Checkpoint刷臟的主要目的是提供一個已知的一致狀態(tài)點(diǎn)，以便于系統(tǒng)崩潰后快速恢復(fù)。通過定期創(chuàng)建這些一致狀態(tài)點(diǎn)，可以限制恢復(fù)過程中需要處理的日志量。

上面的刷臟機(jī)制還是比較容易理解的，PG中最不好理解的就是Backend也有寫臟塊的行為，而在其他數(shù)據(jù)庫中，這個工作完全是由后臺進(jìn)程來完成的。當(dāng)一個Backend進(jìn)程需要讀取一個新的數(shù)據(jù)塊到共享緩沖區(qū)中，但當(dāng)前沒有可用的空閑緩沖區(qū)時，就會觸發(fā)緩沖區(qū)替換機(jī)制（如使用 ClockSweep 算法）。如果選中的替換頁面是臟頁（Dirty Page），那么該頁面必須被寫回磁盤。

這個機(jī)制存在一個比較大的問題，那就是很可能一個SELECT操作操作會產(chǎn)生寫IO操作，從而讓某個SELECT操作的執(zhí)行延時加大。我前兩天也談到Oracle也存在一些引起執(zhí)行效率不穩(wěn)定的行為。不過Oracle的這些行為發(fā)生的概率極低，甚至在一些負(fù)載不是特別大的系統(tǒng)中很少遇到。而在PG中我們經(jīng)常會遇到這些情況的。

圖片

這是我們生產(chǎn)環(huán)境的一個PG 14數(shù)據(jù)庫，可以看出，真正由BGWriter刷臟的數(shù)量只有162，而Backend刷臟的數(shù)量為120萬塊。似乎BGWriter有點(diǎn)不務(wù)正業(yè)了。

這種情況的發(fā)生與PG數(shù)據(jù)庫的設(shè)計(jì)初衷有關(guān)，PG數(shù)據(jù)庫作為最為流行的開源數(shù)據(jù)塊之一，從開始并不是為高并發(fā)、高負(fù)載的企業(yè)級應(yīng)用設(shè)計(jì)的，雖然這些年其企業(yè)級特性越來越多，但是一些根子上的問題還是沿用了早期的設(shè)計(jì)。為了適應(yīng)早期的低成本IO設(shè)備，PG在性能上做出了大量的妥協(xié)。因?yàn)镕ULL PAGE WRITE機(jī)制的存在，導(dǎo)致了PG數(shù)據(jù)庫總是希望臟塊能夠盡可能比較晚地回寫到存儲系統(tǒng)中，Checkpoint也盡可能的不要太快。將刷臟工作分散到大量的Backend中去，也是對IO的一種妥協(xié)，一方面可以緩解Checkpoint過重對IO的影響，一方面也簡化了Backend在共享緩沖區(qū)不足時重用臟塊的處置方法。

曾經(jīng)在和一個搞PG的朋友談到今天討論的問題的時候，他十分興奮地提出他的觀點(diǎn)，他認(rèn)為PG這方面的設(shè)計(jì)十分優(yōu)秀，十分巧妙。我倒是有些不同的觀點(diǎn)，認(rèn)為這是PG數(shù)據(jù)庫成為高負(fù)載的企業(yè)級數(shù)據(jù)庫路上的一個必須優(yōu)化的攔路虎。在現(xiàn)代硬件條件下，這方面的設(shè)計(jì)完全可以做優(yōu)化了。我想隨著AIO/DIO等IO技術(shù)的引進(jìn)，消除Backend寫臟塊的條件也逐步成熟了。

今天時間有限，我們先談到這里吧，明天我將繼續(xù)這個話題，討論一下，基于如此復(fù)雜的PG刷臟機(jī)制，DBA改如何去調(diào)整他們的數(shù)據(jù)庫，從而適應(yīng)自己的業(yè)務(wù)場景。明天再聊吧。