ダーティページを減らすライタープロセス

ダーティページを減らすライタープロセス

   そこで重要となるのがPostgreSQL 8.0から搭載されたライタープロセスです。このプロセスはバックグラウンドで共有バッファを監視して、ダーティページを少しずつハードディスクに書き出 してくれます（図1）。それも次に捨てられる可能性の高いページから優先的に書き出してくれるので、トランザクションのレスポンスタイムの低下を防ぐこと ができるのです。

図1：ライタープロセス
 

   またこの動作によりダーティページを減らす効果が働くため、チェックポイント処理の所要時間も短くなり、トランザクション性能の悪い期間も最小限にできるのです。

ライタープロセスのパラメータ

   ライタープロセスの調整パラメータは3つあります。

   bgwriter_delayはどの程度の頻度で共有バッファを監視するかを指定します。デフォルトは200で、これは200msに1回共有バッファを監視するという設定になります。

   bgwriter_percentは1回の監視において書き出すダーティページ数の上限を、総ダーティページ数を100%とした割合で指定します。デフォルトは1%です。

   bgwriter_maxpagesは1回の監視において書き出すダーティページ数の上限をページ数で指定します。デフォルトは100ページです。 実際に有効となる上限値はbgwriter_maxpagesとbgwriter_percentとで指定されたページ数のうち小さい方です。

   ちなみにbgwriter_percentを100%に設定すると、書き出すページ数をbgwriter_maxpagesのみで制御できるので、比較的分かりやすくなると思います。

ライタープロセスの調整

   残念ながらライタープロセスの調整において絶対的な目安というのはなさそうです。サーバマシン の性能などで最適値は変わってきます。またライタープロセスに何を求めるかでも設定値は変わってきます。理想的にはベンチマークなどを行って最適値を見つ けることになります。

   ところで、ダーティページを減らすことによってレスポンスタイムの改善とチェックポイント時の性能劣化を防げることを説明しました。ライタープロセ スによって2つの効果が得られるわけですが、実は現状のライタープロセスの実装では同時に2つを得るのは難しいのです。ですから実際にはどちらか一方を 狙ってチューニングすることになります。

レスポンスタイムの改善を狙うなら

   レスポンスタイムの改善を行いたい場合には、共有バッファ内の次に捨てられる可能性の高いダー ティページだけを書き出せば良いわけですから、一度に書き出すページ数は少なくて大丈夫です。つまりbgwriter_maxpagesをグッと減らすと 良い結果が得られます。

   この設定によりライタープロセス自体の処理が軽くなり、サーバ全体のパフォーマンスを底上げできます。ただし共有バッファ中の全ダーティページを減 らす効果は薄いので、チェックポイント時の性能劣化を防ぐ力は弱いです。ダーティページがあまり発生しない参照系のデータベースサーバに向いた設定といえ ます。なおPostgreSQL 7.4まではこちらに近い性格でした。