TOP
＞
設計・移行・活用
＞ ダーティページを減らすライタープロセス
今すぐできるPostgreSQLチューニング
第３回：性能か安定か？ライタープロセスのチューニング
著者：
日本PostgreSQLユーザ会 片岡 裕生
2005/8/3
前のページ
1
2
3
次のページ
ダーティページを減らすライタープロセス
そこで重要となるのがPostgreSQL 8.0から搭載されたライタープロセスです。このプロセスはバックグラウンドで共有バッファを監視して、ダーティページを少しずつハードディスクに書き出してくれます（図1）。それも次に捨てられる可能性の高いページから優先的に書き出してくれるので、トランザクションのレスポンスタイムの低下を防ぐことができるのです。
図1：ライタープロセス
またこの動作によりダーティページを減らす効果が働くため、チェックポイント処理の所要時間も短くなり、トランザクション性能の悪い期間も最小限にできるのです。
ライタープロセスのパラメータ
ライタープロセスの調整パラメータは3つあります。
bgwriter_delay
bgwriter_percent
bgwriter_maxpages
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つを得るのは難しいのです。ですから実際にはどちらか一方を狙ってチューニングすることになります。
※注：
次期PostgreSQL 8.1ではこの点が改善されており、同時に2つの効果を得られるようになっています。調整パラメータも2つの効果ごとに指定するため、5項目に増えています。
レスポンスタイムの改善を狙うなら
レスポンスタイムの改善を行いたい場合には、共有バッファ内の次に捨てられる可能性の高いダーティページだけを書き出せば良いわけですから、一度に書き出すページ数は少なくて大丈夫です。つまりbgwriter_maxpagesをグッと減らすと良い結果が得られます。
この設定によりライタープロセス自体の処理が軽くなり、サーバ全体のパフォーマンスを底上げできます。ただし共有バッファ中の全ダーティページを減らす効果は薄いので、チェックポイント時の性能劣化を防ぐ力は弱いです。ダーティページがあまり発生しない参照系のデータベースサーバに向いた設定といえます。なおPostgreSQL 7.4まではこちらに近い性格でした。
前のページ
1
2
3
次のページ
著者プロフィール
日本PostgreSQLユーザ会 片岡 裕生
1995年よりインターウィズという屋号で個人事業を営む。普段はPostgreSQLを用いたウェブアプリケーション開発などを行う。各コンピュータ情報誌にてPostgreSQL関連記事や連載を執筆。日本PostgreSQLユーザ会の創立メンバーの1人で、同会の技術担当理事、PostgreSQLのしくみ分科会座長を経て、2004年度からは理事長を勤める。
INDEX
第3回：性能か安定か？ライタープロセスのチューニング
今回のチューニング
ダーティページを減らすライタープロセス
チェックポイント時の性能劣化を防ぐなら
