PostgreSQL 9.3.2文書
前のページ	上に戻る	第 29章信頼性とログ先行書き込み	次のページ

29.4. WALの設定

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

チェックポイントは、一連のトランザクションにおいて、そのチェックポイント以前に書かれた全ての情報によりヒープとインデックスファイルがすでに更新されていることを保証する場所です。チェックポイントの時刻において、全てのダーティページデータはディスクにフラッシュされ、特殊なチェックポイントレコードがログファイルに書き込まれます。 (変更されたレコードは以前にWALフラッシュされています。) クラッシュした時、クラッシュからの復旧処理は最後のチェックポイントレコードを見つけ、ログの中でどのレコード（これはredoレコードと呼ばれています）から復旧処理がREDOログ操作を開始すべきかを決定します。このチェックポイント以前になされたデータの変更は、すでにディスク上にあることが保証されています。従って、チェックポイント後、redoレコード内のそのチェックポイント以前のログセグメントは不要となり、再利用または削除することができます（WALアーカイブが行われる場合、このログセグメントは削除もしくは再利用される前に保存されなければなりません）。

チェックポイント処理は、全てのダーティデータページをディスクへ書き出すため、大きなI/O負荷を発生させます。このため、チェックポイント処理は絞り込まれます。そうするとI/Oはチェックポイント開始から次のチェックポイントが開始する以前に停止します。これは、チェックポイント処理中の性能劣化を極力抑える効果があります。

サーバのチェックポインタプロセスは自動的にチェックポイントを頻繁に実行します。 checkpoint_segmentsログセグメント数に達するか、またはcheckpoint_timeout秒が経過するか、どちらかの条件が満たされるとチェックポイントが開始されます。デフォルトの設定では、それぞれ3セグメントと300秒(5分)となっています。前回のチェックポイント以降書き出すWALがない場合、checkpoint_timeoutが経過したとしても新しいチェックポイントが飛ばされます。 WALアーカイブ処理を使用しており、かつ、データ損失の可能性を限定するためにファイルのアーカイブ頻度に対する下限を設定したい場合、このチェックポイントパラメータではなくarchive_timeoutパラメータを調節しなければなりません。また、CHECKPOINT SQLコマンドで強制的にチェックポイントを作成することもできます。

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

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

ページ書き出しの集中による入出力システムの溢れを防ぐために、チェックポイント期間のダーティバッファの書き出しは一定の期間に分散されます。この期間はcheckpoint_completion_targetにより制御され、チェックポイント間隔の割合として指定されます。 I/Oの割合は、チェックポイントの起動時からcheckpoint_segments WALセグメントが消費された時、あるいは、指定したcheckpoint_timeout秒が経過した時、このどちらかが発生するとすぐに、チェックポイントが完了するように調整されます。デフォルトの0.5という値では、PostgreSQLは、次のチェックポイントが始まるまでのおよそ半分の時間で各チェックポイントが完了するものと想定できることになります。通常の操作においてほぼ最大のI/Oスループットに近いようなシステムでは、チェックポイントにおけるI/O負荷を減らすためにcheckpoint_completion_targetを増やすことを勧めます。この欠点は、延長されたチェックポイントがリカバリ時に影響をあたえることです。リカバリ時に使用できるように、より多くのWALセグメントを保持する必要があるためです。 checkpoint_completion_targetを最大の1.0に設定することもできますが、より低く抑えること（おそらく最大で0.9）が最善です。チェックポイントには、ダーティバッファを書き出す以外の活動も含まれているからです。 1.0という設定は、ある時点でチェックポイントが完了しなくなるという結果に陥ります。これは必要なWALセグメント数が想定以上に変動することになり、性能の劣化が発生することになります。

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

アーカイブからのリカバリもしくはスタンバイモードにおいて、サーバでは定期的に通常運用でのチェックポイント処理と似たリスタートポイント処理を行います。これは、すでに再生されたWALを再度読み込む必要がないよう、ディスクに現在の状態を強制的に書き込み、pg_controlファイルを更新します。またpg_xlogディレクトリの中の古いログセグメントを再利用できるようにします。リスタートポイント処理はチェックポイントが記録された時にしか実施されないので、マスタ側のチェックポイント処理よりも発生頻度は低いでしょう。再開始点は、最後の再開始点より少なくともcheckpoint_timeout秒が経過しているとすれば、チェックポイントレコードが到達された時点で始動されます。スタンバイモードにおいて、再開始点はもし最後の再開始点から最低限checkpoint_segmentsログセグメントが再生された場合に、同様始動されます。

よく使われる2つの内部用WAL関数があります。 XLogInsertとXLogFlushです。 XLogInsertは共有メモリ上のWALバッファに新しいレコードを挿入します。新しいレコードを挿入する余地がない時は、XLogInsertは、満杯になったWALバッファを書き込み（カーネルキャッシュに移動）しなければいけません。これは望ましいことではありません。なぜなら、データベースへの低レベルの変更（例えば行の挿入）の度にXLogInsertが呼ばれますが、そのような場合には変更を受けたページに対して排他ロックがかかっており、それゆえこの操作は可能な限り高速に実行されなければなりません。さらに悪いことには、WALバッファへの書き込みの際に、さらに時間がかかる、強制的な新しいログセグメントの生成が必要となるかもしれません。通常、WALの書き込み、吐き出しはXLogFlush要求で実施されます。これはたいていの場合、トランザクションコミットの際に永続的な記憶領域にトランザクションレコードが吐き出されることを保証するために行われます。ログ出力が大量に行われるシステムでは、XLogInsertによって必要となる書き込みを防ぐほどにはXLogFlush要求が頻繁に起こらないかもしれません。そういうシステムでは、wal_buffersパラメータを変更してWALバッファの数を増やしてください。 full_page_writesが設定され、かつ、システムが高負荷状態である場合、wal_buffersを高くすることで、各チェックポイントの直後の応答時間を滑らかにすることができます。

commit_delayパラメータは、XLogFlush内でロックを取得してからグループコミット上位者が何マイクロ秒休止するかを定義します。一方、グループコミット追従者は上位者の後に並びます。全てが上位者の結果として生ずる同期操作によりフラッシュされるように、この遅延は他のサーバプロセスがそれらのコミットレコードをWALバッファに追加することを許容します。 fsyncが有効でないか、またはcommit_siblingsより少ない他のセッションがその時点で活動しているトランザクションであれば休止は行われません。ほかの何らかのセッションが直ぐにでもコミットするという起こりそうにない時の休止を避けるものです。いくつかのプラットホームにおいて、休止要求の分解能は10ミリ秒で、どんな１から10000ミリ秒の間の非ゼロであるcommit_delay設定は同じ効果となることを覚えておいてください。いくつかのプラットフォームで、休止操作はパラメータによって要求された時間よりわずかに長くなることも覚えておいてください。

commit_delayの目的はそれぞれのフラッシュ操作のコストを同時実行されるコミットのトランザクションに渡って償却することから（潜在的にはトランザクションの待ち時間の代償により）、設定が知的に選択される以前にそのコストが定量化される必要があります。そのコストが高ければ高いほど、commit_delayがその時点までトランザクションの処理量が増加すると期待されます。 pg_test_fsyncプログラムは、一つのWALフラッシュが必要とするマイクロ秒単位の平均時間を計測するために使用可能です。プログラムが報告する単一の8kb書き込み操作のあとのフラッシュ平均時間の２分の１の値は、しばしばcommit_delayの最も効果的な設定です。従って、この値は特定の作業負荷を最適化する時に使用する開始時点として推奨されます。 WALログが高遅延の回転ディスクに格納されているとき、commit_delayのチューニングは特に有効であることから、半導体ドライブまたはバッテリー・バックアップされている書き込みキャッシュ付きのRAIDアレーのような、特別に高速な同期時間を所有する格納メディア上であってもメリットは特筆すべきものです。しかし、このことは代表的作業負荷に対して間違いなく検証されなければなりません。 commit_siblingsの高い値は、これらの状況で使用されなければならず、一方より小さなcommit_siblingsの値は高遅延メディア上でしばしば有用です。余りにも高い値のcommit_delayを設定すると、ほぼ間違いなくトランザクションの負荷の総計が被るトランザクション遅延を大幅に増加させることになります。

commit_delayが(デフォルトの）ゼロに設定されると、グループコミットという種類が発生することが依然としてあります。しかし、それぞれのグループは前回のフラッシュ操作（あった場合）が発生したなかでの期間中にそれぞれのコミットレコードをフラッシュする必要があった時点に到達したセッションのみから成ります。上位のクライアントにおいて"gangway effect"が起こりそうだと計量すると、commit_delayがゼロであってもグループコミットの効果が著しく、そして従い、commit_delayを明示的に設定しても役立だちません。 commit_delayの設定は（１）いくつかの同時実行するコミットトランザクションが存在すること、そして（２）コミット度合いによりある程度までスループットが制限されている場合に役立ちます。しかし、高い回転待ち時間の場合、この設定はわずか二つのクライアントのトランザクションスループットを増加される効果があります（言いかえれば、一つの兄弟（sibling）トランザクションを所有する単一のコミットするクライアントです）。

wal_sync_methodパラメータはPostgreSQLがカーネルに対してWAL更新のディスクへの書き込みを要求する方法を決定します。 fsync_writethroughを除き、どういう設定でも信頼性は同じはずです。fsync_writethroughは他のオプションがそうしないときでも、時々ディスクキャッシュの書き出しを強制することができます。しかしながら、プラットフォームによってどれが一番速いのかがまったく違います。 pg_test_fsyncプログラムを使って異なるオプションの速度テストを行うことができます。ちなみに、このパラメータはfsyncが無効になっている場合は役に立ちません。

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

前のページ	ホーム	次のページ
非同期コミット	上に戻る	WALの内部