PostgreSQLのチューニング
いつも悩むのはこのチューニングで今回は、特にSolaris側の設定が必要なのかどうかもわからず随分悩みました。結局、Solaris10ではカーネル側の設定は必要ないものとしました。（本当かいな！）
実際、良くわからないのですが、Solaris10のカーネルチューニングというsunから配布されているマニュアルを見ると、Solaris10ではそれ以前のバージョンと違い、各種パラメータが大きく設定されているので、自動チューニングで良いはずだ、といったような説明があります。また、調べても共有メモリの既定値がいくらになっているかさえわからず、へたにさわる必要もないかと思い、カーネルについてはチューニングなしで運用に入りました。
postgresql.confについてはメモリーを2Gbyte乗せたこともあって、下記の設定をデフォルトから変更しました。ログはこれまではとらないで、silent_mode = on で使用していましたが、今回は始めてSolarisを使用するので、当面、ログを取ることにしました。（今のところ、ログをみても特に問題ないので、近々、ログを取るのをやめようかと思っています。）
listen_address = '*'
max_connections = 64
shared_buffers = 50000 #400M
temp_buffers = 5000 #40M
work_mem = 10000 #10M
wal_sync_method = fdatasync
commit_delay = 10
effective_cache_size = 5000 #40M 2G*2%
random_page_cost = 3
redirect_stderr = on
log_filename = '%a.log'
log_truncate_on_rotation = on
log_min_error_statement = 'error'
log_line_prefix = '<%t %u %d %p>'
今回、チューニングにあたって『PostgreSQL完全攻略ガイド 改訂第５版 石井達夫著 技術評論社』を購入しました。第２版、第３版と続いて第５版を買ってしまいました。実際、大分変わっているので、チューニングに関しては第３版はPostgreSQL Ver8.1では参考になりません。特にメモリーは安価になって今回のように2Gbyte乗せても大した費用がかからなくなり、shared_bufferについての設定値は全く変わりました。8.1の性能からいうと100000くらいに設定するのがベストとのことです。取り敢えず、100000に設定してみて起動しないようなら減していくといった説明になっています。
実際やってみると100000では起動せず、半分の50000にしました。
Solarisのshmmaxを設定してやれば起動するようになるのかもしれませんが、まあ、前回はメモリー1Gbyteで4096にして運用していたので、起動しさえすれば50000でも良いかと思います。50000は少し大きすぎるくらいで、今のところ、運用時にswapしている様子もないので50000で行こうと思います
wal_sync_methodはいままで既定値のfsyncから変更したことはなかったのですが、最近Linuxではfdatasyncが普通になっているようなのでこうしました。Solarisの運用実績を調べてみると、open_datasyncというものもありました。
commit_delay=10は攻略ガイドの説明にマルチコアの場合の設定として紹介があるのでこうしました。
effective_cache_size = 5000 #40M 2G*2%
というのは共有バッファの設定ですが、Solaris10のカーネルチュニングに共有バッファの既定値は実メモリの2%という記述があり、2Gbyte×0.02=40Mbyteとしました。
random_page_cost = 3 はQUERY TUNIGの設定ですが、やはり攻略ガイドの説明を参考にしました。
結果として、更新前と比較して速度はあまり変わりませんでした。どちらかというと、別の理由で遅くなった感じがします。（後述）
いつも悩むのはこのチューニングで今回は、特にSolaris側の設定が必要なのかどうかもわからず随分悩みました。結局、Solaris10ではカーネル側の設定は必要ないものとしました。（本当かいな！）
実際、良くわからないのですが、Solaris10のカーネルチューニングというsunから配布されているマニュアルを見ると、Solaris10ではそれ以前のバージョンと違い、各種パラメータが大きく設定されているので、自動チューニングで良いはずだ、といったような説明があります。また、調べても共有メモリの既定値がいくらになっているかさえわからず、へたにさわる必要もないかと思い、カーネルについてはチューニングなしで運用に入りました。
postgresql.confについてはメモリーを2Gbyte乗せたこともあって、下記の設定をデフォルトから変更しました。ログはこれまではとらないで、silent_mode = on で使用していましたが、今回は始めてSolarisを使用するので、当面、ログを取ることにしました。（今のところ、ログをみても特に問題ないので、近々、ログを取るのをやめようかと思っています。）
listen_address = '*'
max_connections = 64
shared_buffers = 50000 #400M
temp_buffers = 5000 #40M
work_mem = 10000 #10M
wal_sync_method = fdatasync
commit_delay = 10
effective_cache_size = 5000 #40M 2G*2%
random_page_cost = 3
redirect_stderr = on
log_filename = '%a.log'
log_truncate_on_rotation = on
log_min_error_statement = 'error'
log_line_prefix = '<%t %u %d %p>'
今回、チューニングにあたって『PostgreSQL完全攻略ガイド 改訂第５版 石井達夫著 技術評論社』を購入しました。第２版、第３版と続いて第５版を買ってしまいました。実際、大分変わっているので、チューニングに関しては第３版はPostgreSQL Ver8.1では参考になりません。特にメモリーは安価になって今回のように2Gbyte乗せても大した費用がかからなくなり、shared_bufferについての設定値は全く変わりました。8.1の性能からいうと100000くらいに設定するのがベストとのことです。取り敢えず、100000に設定してみて起動しないようなら減していくといった説明になっています。
実際やってみると100000では起動せず、半分の50000にしました。
Solarisのshmmaxを設定してやれば起動するようになるのかもしれませんが、まあ、前回はメモリー1Gbyteで4096にして運用していたので、起動しさえすれば50000でも良いかと思います。50000は少し大きすぎるくらいで、今のところ、運用時にswapしている様子もないので50000で行こうと思います
wal_sync_methodはいままで既定値のfsyncから変更したことはなかったのですが、最近Linuxではfdatasyncが普通になっているようなのでこうしました。Solarisの運用実績を調べてみると、open_datasyncというものもありました。
commit_delay=10は攻略ガイドの説明にマルチコアの場合の設定として紹介があるのでこうしました。
effective_cache_size = 5000 #40M 2G*2%
というのは共有バッファの設定ですが、Solaris10のカーネルチュニングに共有バッファの既定値は実メモリの2%という記述があり、2Gbyte×0.02=40Mbyteとしました。
random_page_cost = 3 はQUERY TUNIGの設定ですが、やはり攻略ガイドの説明を参考にしました。
結果として、更新前と比較して速度はあまり変わりませんでした。どちらかというと、別の理由で遅くなった感じがします。（後述）
