【JPUG主催】PostgreSQLカンファレンス2020【11月13日開催】
他のバージョンの文書 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

25.2. WALの設定

データベースの性能に影響するようなWALに関連した設定パラメータが複数あります。 この節では、その使い方を説明します。 サーバ設定パラメータの設定方法についての詳細は項16.4を参照してください。

チェックポイントは、一連のトランザクションにおいて、それ以前にログされた全ての情報でデータファイルが更新されていることが保証されている時点を指します。 チェックポイントでは、全てのダーティデータページがディスクに吐き出され、特別なチェックポイントレコードがログファイルに書き込まれます。 その結果、クラッシュが発生した際に、ログの中でどのレコード(これはredoレコードと呼ばれています)から復旧処理がREDOログ操作を開始すべきかを知ることができます。 なぜなら、redoレコード以前にデータファイルに対して行われた変更はすでにディスク上に記録済みだからです。 チェックポイント処理が実施された後、redoレコード以前の全てのログセグメントは不要となり、削除、または再利用することができます。 (WAL アーカイブが行われる場合、このログセグメントは削除もしくは再利用される前に保存されなければなりません。)

サーバのバックグランドライタプロセスは自動的にチェックポイントを頻繁に実行します。 checkpoint_segmentsログセグメント数に達するか、またはcheckpoint_timeout秒が経過するか、どちらかの条件が満たされるとチェックポイントが作成されます。 デフォルトの設定では、それぞれ3セグメントと300秒となっています。 また、CHECKPOINT SQLコマンドで強制的にチェックポイントを作成することもできます。

checkpoint_segmentscheckpoint_timeout、またはその両者を減少させると、チェックポイントはより頻繁に行われます。 これにより、(再処理に要する時間がより少なくなりますので、)クラッシュ後の修復は高速になります。 しかし、より頻繁に行われるようになる、変更されたデータページの吐き出しにより増大するコストとバランスを考えなければなりません。 更に、データページの一貫性を保証するために、各チェックポイント後の最初に変更されるデータページは、そのページ全体の内容がログに保存されることになります。 このように、チェックポイントの間隔を少なくすることは、WALログへの出力を増加させ、間隔を短くする目的の一部を無意味にします。 また、確実により多くのディスクI/O が発生します。

チェックポイントはかなり高価なものです。 1番の理由は、この処理は現時点の全てのダーティバッファを書き出す必要があること、2番目の理由は、上記のようにその後に余計なWALの書き込みが発生することです。 そのため、チェックポイント用のパラメータを高くし、チェックポイントがあまりにも頻発することがないようにすることを勧めます。 簡単なチェックポイント用のパラメータの健全性検査として、checkpoint_warningパラメータを設定することができます。 チェックポイントの発生間隔がcheckpoint_warning秒未満の場合、checkpoint_segmentsの増加を勧めるメッセージがサーバのログに出力されます。 このメッセージが稀に現れたとしても問題にはなりませんが、頻出するようであれば、チェックポイントの制御パラメータを増加させるべきです。

WALセグメントファイルは少なくとも1つあり、また、通常は 2 * checkpoint_segments + 1 より多くはありません。 各セグメントファイルは通常16MB(このサイズはサーバのコンパイル時に変更可能です)です。 このことから、WALで必要とされる領域を推定できます。 普通、古いセグメントファイルが不要になった時、それらは再利用(将来順番に使われるセグメントとなるように名前が変更)されます。 短時間のログ出力のピークのためにセグメントファイル数が 2 * checkpoint_segments + 1 を越えた場合、システムは、この上限以下になるまで、不要になったセグメントファイルを再利用せずに、削除します。

よく使われる2つのWAL関数があります。 LogInsertLogFlushです。 LogInsertは共有メモリ上のWALバッファに新しいレコードを挿入します。 新しいレコードを挿入する余地が無い時は、LogInsertは、満杯になったWALバッファを書き込み(カーネルキャッシュに移動)しなければいけません。 これは望ましいことではありません。 なぜなら、データベースへの低レベルの変更(例えば行の挿入)の度にLogInsertが呼ばれますが、そのような場合には変更を受けたページに対して排他ロックがかかっており、それ故この操作は可能な限り高速に実行されなければなりません。 さらに悪いことには、WALバッファへの書き込みの際に、さらに時間がかかる、強制的な新しいログセグメントの生成が必要となるかもしれません。 通常、WALの書き込み、吐き出しはLogFlush要求で実施されます。 これはたいていの場合、トランザクションコミットの際に永続的な記憶領域にトランザクションレコードが吐き出されることを保証するために行われます。 ログ出力が大量に行われるシステムでは、LogInsertによって必要となる書き込みを防ぐほどにはLogFlush要求が頻繁に起こらないかもしれません。 そういうシステムでは、wal_buffers設定パラメータを変更してWALバッファの数を増やしてください。 デフォルトのWALバッファの数は8です。 この数を増やすと共有メモリの使用量に影響があります。 (現時点でデフォルト以上のwal_buffersの増加について、それが有用であることを勧める根拠はないことに注意しなければなりません)

commit_delayパラメータは、LogInsertがコミットレコードをログに書き込んでからLogFlushが行われるまでの間にサーバプロセスが何マイクロ秒休止するかを定義します。 この遅延により、他のサーバプロセスがコミットレコードをログに書き込んだ後、それら全てのログレコードを1回のログ同期で吐き出すことができます。 fsyncが無効な場合や、commit_siblingsよりも少ない数のセッションしか現在アクティブなトランザクションに存在しない場合は、休止しません。 この処理により、すぐにコミットしそうなセッションが無い時でも休止してしまうことを防ぐことができます。 たいていのプラットフォームでは、休止の最小単位は10ミリ秒であることに注意してください。 ですから、1マイクロ秒から10,000マイクロ秒までの間での0以外のcommit_delayの設定は、同じ効果になるでしょう。 これらのパラメータの適切な値はまだ明確ではありません。 実験が必要です。

wal_sync_methodパラメータはPostgreSQLがカーネルに対してWAL更新のディスクへの書き込みを要求する方法を決定します。 どういう設定でも信頼性は同じはずですが、プラットフォームによってどれが一番速いのかが全く違います。 ちなみに、このパラメータはfsyncが無効になっている場合は役に立ちません。

wal_debug設定パラメータを有効にすることで、LogInsertLogFlushというWAL呼び出しは毎回サーバログにログが残ります。 (このパラメータをサポートするようにPostgreSQLをコンパイルする必要があります。) 将来このオプションはより一般的な機構に置き換わる予定です。