作者宣告:本文是根據外文資料和作者的經驗寫的,如有錯誤請指出更正
postgresql是依靠預寫日誌（wal）的資料庫之一,所有的更改首先被寫入乙個日誌（乙個變化的流）,然後再寫入資料檔案.這提高了資料的安全性,因為在崩潰的情況下,資料庫會使用wal執行恢復,從wal讀取更改並將其重新應用於資料檔案.
雖然這可能會使寫入量增加一倍，但實際上可能會提高效能,使用者只需要等待wal（重新整理到磁碟）,而資料檔案僅在記憶體中修改,然後在後台重新整理. wal寫入本質上是順序寫入的，而對資料檔案的寫入往往是隨機寫入的.
非常頻繁的檢查點（比如幾秒一次）.只保留少量的wal，恢復速度非常快,但會將非同步寫入資料檔案轉換為同步資料檔案,嚴重影響系統效能 （例如增加commit延遲，降低吞吐量）.
因此在實踐中,通常需要合理設定checkpoint_timeout和max_wal_size。
檢查點可以觸發的原因有：
1.直接執行checkpoint命令
2.執行需要檢查點的命令（例如pg_start_backup ， create database或pg_ctl stop|restart等等）
3.達到檢查點配置時間(checkpoint_timeout)
4.max_wal_size已滿（"running out of wal"或"filling wal"）
其中1和2和配置無關的,需要手動觸發的事件.本文主要配置3和4。
postgresql預設配置,預設值一般設定比較保守,以保證在大多數機器上可以執行。
checkpoint_timeout = 5min
max_wal_size = 1gb （postgresql 9.5之前是checkpoint_segments ）
max_wal_size = (3 * checkpoint_segments) * 16mb很難說checkpoint_timeout的"合理"值是什麼,因為它取決於恢復時間（rto）,即可接受的最大恢復間是多少。因為checkpoint_timeout是生成wal所需的時間,而不是恢復時間.wal通常由多個程序生成,而恢復由單個程序執行,這不僅影響本地恢復，還會影響到具有流複製的備機。 當恢復檔案系統快取時，通常會在重新引導之後立即進行恢復。但一般來說，預設值（5分鐘）相當低,普遍採用30分鐘到1小時之間,postgresql 9.6甚至增加了最多1天,建議使用30分鐘。
checkpoint_timeout=30min使用pg_current_xlog_insert_location()檢視實際的wal位置（基本上在檔案中偏移pg_current_xlog_insert_location(),並計算每30分鐘測量的位置之間的差異
啟用log_checkpoints=on,然後從伺服器日誌中提取資訊（每個完成的檢查點將有詳細的統計資訊,包括wal的數量）
使用pg_stat_bgwriter資料,其中還包括關於檢查點數量的資訊（可以結合當前的max_wal_size值的知識）
postgres=# select pg_current_xlog_insert_location();
pg_current_xlog_insert_location
---------------------------------
3d/b4020a58
(1 row)
... after 5 minutes ...
postgres=# select pg_current_xlog_insert_location();
pg_current_xlog_insert_location
---------------------------------
3e/2203e0f8
(1 row)
postgres=# select pg_xlog_location_diff('3e/2203e0f8', '3d/b4020a58');
pg_xlog_location_diff
-----------------------
1845614240
(1 row)
checkpoint_completion_target
除checkpoint_timeout和max_wal_size外,還有乙個引數叫做checkpoint_completion_target,但是要調整它,需要了解什麼是「擴充套件檢查點」的意思
在checkpoint期間,資料庫需要執行以下三個基本步驟：
1.識別共享緩衝區中的所有髒（修改）塊
2.將所有這些緩衝區寫入磁碟（或更改為檔案系統快取）
3.fsync()所有修改的檔案寫入磁碟
只有當所有這些步驟完成時,檢查點才能被認為是完整的.您可以盡可能快地執行這些步驟,即一次性寫入所有髒緩衝區,然後在檔案上呼叫fsync,實際上這是postgresql 8.2開始使用的.但是由於大量寫入時檔案系統的快取記憶體飽和,會影響使用者會話,導致i/o停頓.為了解決這個問題,postgresql 8.3引入了「擴充套件檢查點」的概念,而不是一次寫入所有的資料,寫入時間很長,這給了作業系統時間來重新整理後台的髒資料,從而使降低fsync()呼叫成本.
vm.dirty_expire_centisecs = 3000注意： 當涉及到核心引數時,需要調整vm.dirty_background_bytes.在具有大記憶體的系統上,預設值設高,允許核心在檔案系統快取累積的資料就越多.核心通常決定一次衝寫入,從而減少了擴充套件檢查點的好處。
返回到checkpoint_completion_target = 0.5這個配置引數說明所有的寫入都要完成,到下乙個檢查點有多遠.
checkpoint_completion_target = 0.5留給系統的2.5分鐘可能看起來很多,考慮到超時時間(checkpoint_timeout)只有30秒.您可以將checkpoint_completion_target例如增加到0.85，這將留給系統大約45秒，比它需要的30秒多一點。這不建議,因為在密集寫入的情況下,檢查點可能比max_wal_size更快地觸發,比5分鐘之後,留給作業系統時間少於30秒。
然而,處理寫入密集型工作負載的系統不太可能執行更高的checkpoint_timeouts值,預設的completion_target值顯然太低.例如,超時設定為30分鐘,它強制資料庫在前15分鐘（寫入速率的兩倍）中執行所有寫入,然後在剩餘的15分鐘內空閒。
替代方案是可以嘗試使用此公式大致設定checkpoint_completion_target
(checkpoint_timeout - 2min) / checkpoint_timeout概要現在你應該知道檢查點的目的是什麼,也有了調整它們的基礎.總結一下：
大多數檢查點應該是基於時間的,即由checkpoint_timeout觸發
效能（不頻繁檢查點）與恢復所需時間（頻繁檢查點）之間的妥協
值在15-30分鐘之間是比例合適的,但到1小時不是什麼壞事
在決定checkpoint_timeout後,通過估計wal的數量選擇max_wal_size
設定checkpoint_completion_target以便核心將資料重新整理到磁碟的時間足夠（但不是太多）
還需要調整核心引數vm.dirty_expire_centisecs,vm.dirty_background_bytes以防止核心在頁面快取中累積大量髒資料
檢查點 為什麼要插入檢查點 檢查點的作用
一 為什麼要插入檢查點 檢查點的作用 檢查點記錄被測系統的預期結果，在執行過程中，qtp將預期結果與實際執行結果進行比較，若一致，測試結果報告中，檢查點為passed，否則為failed。只有插入檢查點的 才具有測試能力，檢查功能點是否實現 二 標準檢查點 standard checkpoint 檢...
功能測試檢查點
測試物件 flight 程式 c s 架構 檢查mercury 是否顯示在 之間 dim a,ba window flight reservation winedit order no 4 getroproperty text b cstr a msgbox b 正規表示式檢查 if語句判定成功或者...
lr VuGen（事務 檢查點）
事務的應用 在每乙個請求前後加上transaction 和 end transaction，選單欄insert new step 記錄請求的響應時間，其中end transaction有status選項，有4個選項，若是auto就不用手工判斷事務的執行結果，但這個結果不夠準確。2 統計事務的成功率 ...