TOP設計・移行・活用> チェックポイント時の性能劣化を防ぐなら
今すぐできるPostgreSQLチューニング
今すぐできるPostgreSQLチューニング

第3回:性能か安定か?ライタープロセスのチューニング
著者:日本PostgreSQLユーザ会  片岡 裕生   2005/8/3
前のページ  1  2  3
チェックポイント時の性能劣化を防ぐなら

   チェックポイント時の性能劣化を改善したい場合には、共有バッファ中の全ダーティページを減らすことを目標にしなければなりません。ですからbgwriter_maxpagesは必要に応じて大きな値を設定します。設定値を算出する目安としては次のような考え方ができます。

   チェックポイントの発生間隔はデフォルトで5分ですから、ライタープロセスが200msに1回実行されるとすると、チェックポイントと次のチェックポイントの間にはライタープロセスが1500回実行されることになります。

   1500回ですべての共有バッファをチェックして書き出せるようにと考えると、bgwriter_maxpagesは少なくとも「共有バッファサイズ÷1500」ページ以上は必要ということになります。たとえば共有バッファが16000ページだとすると、bgwriter_maxpagesには10ページ程度を指定すればいいことになり、これを基準値として増減すればいいでしょう。

   ただしあくまでも目安です。何しろダーティページは常に発生しますから、同じページが何度もダーティページになることがあり得るわけで、もしかすると上記の計算結果では全然少ないかもしれません。

   また共有バッファ全体がダーティページになることはほとんどないと考えると、ベースを16000ページとした上記の計算結果は大きすぎるかもしれません。ですが両方の可能性を考慮して「やっぱりちょうど良いんじゃないか?」という楽観主義はいかがでしょうか。なおこちらのチューニングはピーク性能ではなく安定性を重視するシステムに向いた設定といえます。


テスト用サーバマシンをチューニング

   それでは今回もテスト用サーバマシンをチューニングしてみましょう。ここではベンチマークによる比較で性能向上を目指しているということもあり、レスポンスタイムの向上を狙った設定を行いたいと思います。これはbgwriter_maxpagesをグッと減らす方向ですから、デフォルトで100ページだったものを一気に4ページまで減らすことにします。なおテスト用サーバマシンの仕様などは第1回の記事を参照してください。

   PostgreSQLの設定を変更するには、エディタなどで設定ファイルを編集します。PostgreSQLをソースからインストールしたのであれば、設定ファイルは/usr/local/pgsql/data/postgresql.confです。ディレクトリ構成を変更している場合や、RPM等でインストールされた場合には、設定ファイルの場所が異なる場合がありますので、ご利用の環境に合わせて読み替えてください。

   設定ファイル(postgresql.conf)をviなどのテキストエディタで開き、"bgwriter_maxpages"の指定をしている箇所を100ページから4ページに書き換えます。行頭の"#"記号でコメントアウトされている場合には忘れずに解除してください。

bgwriter_maxpages = 4           # 0-1000 buffers max per round

   設定ファイルを保存した後、PostgreSQLサーバを再起動すれば準備OKです。


チューニングの結果

   それでは、bgwriter_maxpagesを100から4と小さくした場合にPostgreSQLの性能がどのように変わるのかを確認してみましょう。前回とまったく同じ条件でベンチマーク試験を行った結果が図2です。

前回のチューニング結果とライタープロセス調整後の比較
図2:前回のチューニング結果とライタープロセス調整後の比較

   クライアント数に関わりなく全体的に性能が向上しています。この結果は、ライタープロセスが軽くなったことでトランザクション処理に回せるリソースが増え、見かけ上のマシン性能が向上したためと考えることができます。


まとめ

   ライタープロセスのデフォルト設定は、どちらかというとチェックポイント時の性能劣化を防ぐ味付けが強いです。

   ライタープロセスがどんどんダーティページを書き出すため、ライタープロセス自体が結構な量のマシンリソースを消費します。それだけに性能の安定性という点では目を見張るものがありますが、目的によってはそこまで安定志向でなくてもいいよ、という場合もあると思います。そのような場合にはライタープロセスの仕事を軽くしてあげることで、全体的な性能の底上げが可能になります。


次回のチューニング予告

   次回は、同じくPostgreSQL 8.0で導入されたテーブルスペースを活用した例を取り上げる予定です。ハードディスクが2台以上ないと使えない方法ですが、効果はテキメン。きっとハードディスクの増設をしたくなること請け合いです。どうぞお楽しみに!

前のページ  1  2  3


日本PostgreSQLユーザ会 片岡 裕生
著者プロフィール
日本PostgreSQLユーザ会  片岡 裕生
1995年よりインターウィズという屋号で個人事業を営む。普段はPostgreSQLを用いたウェブアプリケーション開発などを行う。各コンピュータ情報誌にてPostgreSQL関連記事や連載を執筆。日本PostgreSQLユーザ会の創立メンバーの1人で、同会の技術担当理事、PostgreSQLのしくみ分科会座長を経て、2004年度からは理事長を勤める。


INDEX
第3回:性能か安定か?ライタープロセスのチューニング
  今回のチューニング
  ダーティページを減らすライタープロセス
チェックポイント時の性能劣化を防ぐなら