在PG的眾多參數中，參數checkpoint相關的幾個參數頗為神秘。這些參數與checkpoint的調度有關，對系統的穩定性還是比較重要的，下面我們為大家解析一下，這要先從PG的數據同步機制談起。 ## PG的數據同步機制 眾所周知，數據庫的后臺進程在執行用戶事務時，發生的數據更改是先寫入緩沖池中，對應PG就是shared buffers。PG的緩沖池一般設置為總內存的1/4左右，緩沖池里面的這些數據更改，在事務提交時，是無需同步寫入到磁盤的。因為在事務提交時，會先寫入WAL日志，有了WAL日志，就可以在異常情況下將數據恢復，保障數據安全，因此數據本身是否在提交時寫入磁盤就沒那么重要了。PG是只是在需要的時候，例如臟頁較多時、或一定時間間隔后，才將數據寫回磁盤。 臟頁處理的過程分為幾個步驟。首先是由background writer將shared buffers里面的被更改過的頁面（即臟頁），通過調用write寫入操作系統page cache。在函數BgBufferSync可以看到，PG的background writer進程，會根據LRU鏈表，掃描shared buffers（實際上是每次掃描一部分），如果發現臟頁，就調用系統調用write。可以通過設置bgwriter_delay參數，來控制background writer每次掃描之間的時間間隔。background writer在對一個頁面調用write后，會將該頁面對應的文件（實際上是表的segement，每個表可能有多個segment，對應多個物理文件）記錄到共享內存的數組`CheckpointerShmem->requests`中，調用順序如下： ~~~ BackgroundWriterMain -> BgBufferSync -> SyncOneBuffer -> FlushBuffer -> smgrwrite | | V ForwardFsyncRequest <- register_dirty_segment <- mdwrite ~~~ 最終checkpointer進程通過讀取`CheckpointerShmem->requests`數組，獲得這些request，并放入pendingOpsTable。而真正將臟頁回寫到磁盤的操作，是由checkpointer進程完成的。checkpointer每次也會調用smgrwrite，把所有的shared buffers臟頁（即還沒有被background writer清理過得臟頁）寫入操作系統的page cache，并存入pendingOpsTable，這樣pendingOpsTable存放了所有write過的臟頁，包括之前background writer>已經處理的臟頁。隨后PG的checkpointer進程會根據pedingOpsTable的記錄，進行臟頁回寫操作（注意每次調用fysnc，都會sync數據表的一個文件，文件中所有臟頁都會寫入磁盤），調用順序如下： ~~~ CheckPointGuts->CheckPointBuffers->->mdsync->pg_fsync->fsync ~~~ 如果checkpointer做磁盤寫入的頻率過高，則每次可能只寫入很少的數據。我們知道，磁盤對于順序寫入批量數據比隨機寫的效率要高的多，每次寫入很少數據，就造成大量隨機寫；而如果我們放慢checkpoint的頻率，多個隨機頁面就有可能組成一次順序批量寫入，效率大大提高。另外，checkpoint會進行fsync操作，大量的fsync可能造成系統IO阻塞，降低系統穩定性，因此checkpoint不能過于頻繁。但checkpoint的間隔也不能無限制放大。因為如果出現系統宕機，在進行恢復時，需要從上一次checkpoint的時間點開始恢復，如果checkpoint間隔過長，會造成恢復時間緩慢，降低可用性。整個同步機制如下圖所示：  圖1\. 數據同步機制 ## checkpoint的調度 那么如何調度checkpoint，即控制checkpoint的間隔呢？PG提供了幾個參數：`checkpoint_segments`、`checkpoint_completion_target`和`checkpoint_timeout`。 決定是否做checkpoint有兩個指標維度： 1. 系統的數據修改量。 評估修改量，有兩種方法：一種是記錄shared buffer里面的臟頁有多少，占所有buffer的多大比例；另外一種，記錄用戶事務的數據修改量是多少。如果用系統的臟頁數量或所占比例，來評估修改量，會不太準確，用戶有可能反復修改相同的頁面，臟頁不多，但實際修改量很大，這時候也是應該盡快進行checkpoint，減少恢復時間的。而通過記錄WAL日志的產生量，可以很好的評估這個修改量，所以就有了`checkpoint_segments`這個參數，它用于指定產生多少WAL日志后，進行一次checkpoint。例如設置為16時，產生16個WAL日志文件后（如果每個日志文件的大小為16M，即產生16*16M字節的日志），進行一次checkpoint。判斷是否觸發checkpoint的調用如下： ~~~ XLogInsert->XLogFlush->XLogWirte->XLogCheckpointNeeded ~~~ 2. 距離上一次checkpoint的時間。 也就是在上一次checkpoint后，多長時間必須做一次checkpoint。PG提供了`checkpoint_timeout`這個參數，缺省值為300秒，即如果上一次checkpoint后過了300秒沒有做checkpoint了，就強制做一次checkpoint。 那么另外一個參數`checkpoint_completion_target`是做什么的呢？ ## checkpoint_completion_target 參數 這個看似不起眼的參數其實對checkpoint調度的影響很大。它是怎么使用的呢？checkpoint會調用BufferSync，將所有shared buffers的頁面掃描一遍，如果發現臟頁即調用write，寫入page cache。每次write完一個臟頁后，會調用`IsCheckpointOnSchedule()`這個函數。這個函數的主要邏輯是，判斷新產生的日志文件數除以`checkpoint_segments`，結果是否小于`checkpoint_completion_target`。注意，這里的新產生日志文件數，是checkpoint開始后新產生的日志數，不是從上一次checkpoint結束后的新日志數。如果`IsCheckpointOnSchedule()`返回true，則checkpointer進程會進行sleep，sleep一定時間后，再讀取下一個shared buffers頁面進行write。這樣做的效果是，當所有頁面write完成時，新產生的日志頁面數占`checkpoint_segements`的比例約為`checkpoint_completion_target`的設定值。例如，如果`checkpoint_segements`為16，`checkpoint_completion_target`為0.9，則當上一次checkpoint后，新的第16個日志文件產生后，寫日志的那個進程會觸發一次checkpoint。checkpoiter進程隨即調用`CreateCheckPoint`，做一次checkpoint，checkpointer進程會調用`BufferSync`，掃描shared buffers寫臟頁。此時每次write一個臟頁后，如果新產生的日志文件數小于16*0.9，即15個日志文件時，會進行sleep。最后當write臟頁完成時，從上次checkpoint開始新產生的日志文件約為16+15=31個，即 ~~~ checkpoint_segments + checkpoint_segments * checkpoint_completion_target ~~~ 由此可見，`checkpoint_completion_target`直接控制了checkpoint中的write臟頁的速度，使其完成時新產生日志文件數為上述期望值。 除了日志文件數，`IsCheckpointOnSchedule()`還會檢查從checkpoint開始到現在的時間占`checkpoint_timeout`的比例，是否小于`checkpoint_completion_target`，以決定是否sleep。按`checkpoint_completion_target`為0.9，`checkpoint_timeout`為300秒計算，臟頁write的完成時間距離checkpoint開始的時間，大約是270秒。實際上，這個時間上的約束和產生日志文件數的約束是同時起作用的。 當臟頁全部被write完，就要進行真正的磁盤操作了，即fsync。此時每個文件的fsync之間沒有sleep，是盡快完成的。一般做fsync總時間不會超過10秒，因此會趕在時間間隔到達`checkpoint_timeout`或新日志文件數到達`checkpoint_segments`前(都從checkpoint開始時間點開始算起)結束此次checkpoint。 總結起來，每次checkpoint所耗時間可以用下面的公式計算： ~~~ min（產生checkpoint_segments*checkpoint_completion_target個日志文件的時間，checkpoint_timeout*checkpoint_completion_target）+ 做fsync的時間 ~~~ 比如上面的例子，將會是： ~~~ min (產生15個日志文件的時間，270秒）+ fsync的時間 ~~~ 而這個時間一般小于產生`checkpoint_segments`個日志或`checkpoint_timeout`的時間。這樣綜合的效果是，每產生`checkpoint_segments`個日志或經歷`checkpoint_timeout`的時間做一次checkpoint。在兩次checkpoint的開始時間之間，會在`checkpoint_completion_target`比例的時間點完成臟頁write，隨后很快進行完fsync，如下圖所示：  圖2\. checkpoint過程 以上便是checkpoint的調度機制。我們要注意調整上述幾個參數時，不要讓checkpoint產生過于頻繁，否則頻繁的fsync操作會是系統不穩定。比如，`checkpoint_segments`一般設置為16個以上，`checkpoint_completion_target`設為0.9，`checkpoint_timeout`為300秒，這樣一般checkpoint的間隔能達到1分鐘以上。