思わずなっとく　PostgreSQLの勘所第1回

チェックポイント時の性能劣化を防ぐなら

   チェックポイント時の性能劣化を改善したい場合には、共有バッファ中の全ダーティページを減らすことを目標にしなければなりません。ですから 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：前回のチューニング結果とライタープロセス調整後の比較

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

まとめ

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

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