# 29.4\. WAL 配置 有幾個與WAL相關的參數會影響數據庫性能。本節討論它們的使用。 參閱[Chapter 18](#calibre_link-500)獲取有關服務器配置參數的一般信息。 _檢查點_是事務序列中的點， 在該點之前的所有信息都確保已經寫到數據文件中去了。在檢查點時， 所有臟數據頁都刷新到磁盤并且向日志文件中寫入一條特殊的檢查點記錄。 （變更記錄已經預先刷新到WAL文件了。）在發生崩潰的時候， 崩潰恢復過程查找最后的檢查點記錄，判斷應該從日志中的哪個點(稱為 redo 記錄)開始 REDO 操作， 在該記錄之前對數據文件的任何修改都保證已經寫在磁盤上了。因此，在檢查點之后， 任何在包含 redo 記錄點之前的日志段都不再需要，因此可以循環使用或者刪除。當然， 在進行WAL歸檔的時候，這些日志段在循環利用或者刪除之前必須先歸檔。 刷新所有臟數據頁面到磁盤的檢查點需求會導致顯著的I/O負載，因此，檢查點進行了限制， 在下一個檢查點開始之前，I/O在檢查點開始和結束時開啟；這會在檢查點進行時降低性能損耗。 服務器的檢查點進程每[checkpoint_segments](#calibre_link-1208)個日志段或每 [checkpoint_timeout](#calibre_link-1215)秒就創建一個檢查點，以先到為準。 缺省設置分別是 3 個段和 300 秒（5分鐘）。如果自從前一個檢查點以來沒有WAL寫入， 那么將跳過新的檢查點，即使已經超過了`checkpoint_timeout`。 （如果使用了WAL歸檔并且你希望放置一個低一些的限制在多久文件歸檔一次上，以限制潛在的數據丟失， 你應該調整[archive_timeout](#calibre_link-468)參數而不是檢查點參數。） 我們也可以用 SQL 命令`CHECKPOINT`強制創建一個檢查點。 減少`checkpoint_segments`和/或`checkpoint_timeout` 會更頻繁的創建檢查點。這樣就允許更快的崩潰后恢復(因為需要重做的工作更少)。不過， 我們必須在更快的恢復與更頻繁的刷新臟數據頁所帶來的額外開銷之間進行平衡。并且， 如果開啟了[full_page_writes](#calibre_link-1135)(缺省開啟)，那么還有其它的因素需要考慮。 為了保證數據頁的一致性，在每個檢查點之后的第一次數據頁變化會導致對整個頁面內容的日志記錄。 因此，減小檢查點時間間隔會導致輸出到 WAL 日志中的數據量增加，從而抵銷一部分使用間隔的目標， 并且無論如何都會產生更多的磁盤 I/O 操作。 檢查點的開銷相當高，首先是因為它需要寫出所有當前臟緩沖區，其次是因為導致前面討論過的額外后繼 WAL 流量。 因此把檢查點參數設置得足夠高，讓檢查點發生的頻率降低是明智的。可以通過設置 [checkpoint_warning](#calibre_link-2307)對檢查點參數進行一個簡單自檢。如果檢查點發生的間隔接近 `checkpoint_warning`秒，那么將向服務器日志輸出一條消息，建議你增加`checkpoint_segments` 的數值。偶爾出現這樣的警告并不會導致警報，但是如果出現得太頻繁，那么就應該增加檢查點控制參數。 如果你沒有把`checkpoint_segments`設置得足夠大，那么批量操作的時候 (比如大批的`COPY`傳輸)會導致出現大量此類警告消息。 為了避免大量的塊寫操作塞滿I/O系統，在一段時間內，在檢查點期間寫臟緩沖。這個時間是由 [checkpoint_completion_target](#calibre_link-1643)控制的，作為檢查點時間間隔的一小部分。 調整I/O速率以便當從檢查點開始時給出的`checkpoint_segments`段的分數已使用完， 或已經過了給定的`checkpoint_timeout`秒數時完成檢查點，不管時間哪個更早。 缺省值是0.5，PostgreSQL可以在下次檢查點開始之前用大約一半的時間完成檢查點。 在一個正常操作時就很接近最大I/O吞吐量的操作系統上，可以增加`checkpoint_completion_target` 以降低檢查點時的I/O負載。這樣做的弊端在于會延長檢查點，從而影響恢復時間， 因為會保留更多的在恢復中可能用到的WAL段。盡管`checkpoint_completion_target` 最大可以設置為1.0，最好不要設置那么大，最大0.9，因為檢查點期間的操作不僅僅包括寫臟緩沖區。 設置為1.0極有可能會導致不會按時完成檢查點，從而由于所需的WAL段的數目的意外變化造成性能丟失。 至少會有一個 WAL 段文件，而且通常不會超過(2 + `checkpoint_completion_target`) * `checkpoint_segments` + 1 或`checkpoint_segments` + [wal_keep_segments](#calibre_link-1136) + 1個文件。 每個段文件通常為 16MB(你可以在編譯服務器的時候修改它)。你可以用這些信息來估計WAL需要的空間。 通常，如果一個舊日志段文件不再需要了，那么它將得到回收(重命名為順序的新的可用段)。 如果由于短期的日志輸出高峰導致了超過3 * `checkpoint_segments` + 1個段文件， 那么當系統再次回到這個限制之內的時候，不需要的段文件將被刪除，而不是回收利用。 在歸檔恢復或待機模式時，服務器在正常操作中會定期執行類似于檢查點的_restartpoints_ ：服務器會強制將他的狀態寫入磁盤，更新`pg_control` 文件來表明已經處理了的WAL數據不需要再次掃描，然后便會回收在`pg_xlog`目錄下所有舊日志段文件。 重啟點不能比檢查點運行的更頻繁，因為重啟點只能在檢查點記錄上執行。當到達檢查點記錄時， 如果從最后一個重啟點至少已經過去`checkpoint_timeout`秒，那么觸發重啟點。 在待機模式下，如果自從最后一個重啟點已經至少`checkpoint_segments`個日志段重放， 也會觸發重啟點。 有兩個常用的內部WAL函數`XLogInsert`和`XLogFlush`。 `XLogInsert`用于向共享內存中的WAL緩沖區里添加一條新記錄。 如果沒有空間存放新記錄，那么`XLogInsert`就不得不寫出(向內核緩存里寫) 一些填滿了的WAL緩沖。我們可不想這樣，因為`XLogInsert` 用于每次數據庫低層修改(比如插入記錄)時都要在受影響的數據頁上持有一個排它鎖， 所以該操作需要越快越好；更糟糕的是，寫WAL緩沖可能還會強制創建新的日志段， 它花的時間甚至更多。通常，WAL緩沖區應該由一個`XLogFlush` 請求來寫和刷新，在大部分時候它都是發生在事務提交的時候以確保事務記錄被刷新到永久存儲器上去了。 在那些日志輸入量比較大的系統上，`XLogFlush`請求可能不夠頻繁， 這樣就不能避免`XLogInsert`進行寫操作。在這樣的系統上， 我們應該修改[wal_buffers](#calibre_link-1991)參數的值來增加WAL緩沖區的數量。 如果設置了[full_page_writes](#calibre_link-1135)并且系統相當繁忙， 把`wal_buffers`設置得高一些將有助于在緊隨每個檢查點之后的時間里平滑響應時間。 [commit_delay](#calibre_link-1621)定義了在`XLogFlush` 內請求一個鎖后一組提交領導者進程將要休眠的毫秒數，組提交后面跟著排隊的領導者。 這樣的延遲可以允許其它的服務器進程把它們提交的記錄追加到WAL緩存中， 這樣就可以通過領導者的最終sync操作把所有記錄刷新。如果沒有打開[fsync](#calibre_link-1214) 或者當前少于[commit_siblings](#calibre_link-2308)個處于活躍事務狀態的其它會話時則不會發生休眠； 這樣就避免了在其它事務不會很快提交的情況下睡眠。請注意，在一些平臺上， 休眠要求的分辯率是 10 毫秒，所以任何介于 1 和 10000 微秒之間的非零`commit_delay` 設置的作用都是一樣的。也要注意，在一些平臺上，睡眠操作可能比參數要求的時間稍長一些。 因為`commit_delay`的目的是允許每個刷新操作的開銷分攤給并發的提交事務 （可能是事務潛在開銷），在設置可以明智的選擇錢量化開銷是必須的。開銷越高，`commit_delay` 在一定程度上提高事務吞吐量越有效。[pg_test_fsync](#calibre_link-1619)程序可以用來測量單次WAL刷新操作使用的平均毫秒數。 這個程序報告的平均時間的一半用來在單個8kB寫操作之后刷新，這個時間通常是`commit_delay` 最有效的設置，所以當優化特定負載時，建議使用這個值作為起始點。當WAL日志存儲在高時延旋轉磁盤上時， 調整`commit_delay`是尤其有用的，即使存儲媒體有非常快的sync時間也是有顯著效益的， 比如有電池備用寫緩存的固態硬盤或RAID陣列；但是這應該明確對代表工作負載測試。`commit_siblings` 的更高值應該在諸如此類的情況下使用，而更小值通常對高時延媒體有幫助。注意， 總事務吞吐量太大時，`commit_delay`的設置太高會增加事務時延是極有可能的。 當`commit_delay`設置為0時（缺省），仍然可能發生組提交， 但是每組將只由到達點的會話組成，在這個點他們需要刷新在前一個刷新操作（如果有） 發生時他們的提交記錄。更高的客戶端計數"舷梯效應"往往會發生， 所以組提交的影響會是顯著的，即使`commit_delay`為0， 并且因此明確的設置`commit_delay`往往沒什么用處。設置`commit_delay` 只能幫助以下情況：（1）有一些并發提交事務，（2）吞吐量通過提交率限制到某種程度； 但是對于高旋轉延遲，只有兩個客戶端時，這個設置對增加事務吞入量是有效的（也就是， 單次提交客戶端有一個兄弟事務）。 [wal_sync_method](#calibre_link-1432)參數決定PostgreSQL 如何請求操作系統內核強制將WAL更新輸出到磁盤。只要滿足可靠性， 那么所有選項應該都是一樣的，除`fsync_writethrough`，可以有時強制刷新磁盤高速緩存， 即使其他選項時不這樣做。但是哪個最快則可能和平臺密切相關。你可以使用 [pg_test_fsync](#calibre_link-1619)測試不同選項的速度。請注意如果你關閉了`fsync` 的話這個參數就無關緊要了。 打開[wal_debug](#calibre_link-2309)配置參數(前提是編譯PostgreSQL 的時候打開了這個支持)將導致每次`XLogInsert`和`XLogFlush` WAL 調用都被記錄到服務器日志。這個選項以后可能會被更通用的機制取代。