PostgreSQLのチューニングについて調べてみる

PostgreSQLのパラメータチューニングをしなくてはいけない状況になったのですが、そもそも自分は詳しくPostgreSQLを知ってい訳ではありません。そこで、ネットで情報を探してみます。以下はその時のメモです。

仕組みを知るによいドキュメント

"PostgreSQLのチューニング技法"
PDFですが、PostgreSQLの仕組みを理解するためにはかなりよい資料だと思いました。前提として、DBがおこなっていることの概要は知っている必要がありそうですが、DBが内部的におこなっていることから関係するパラメータについて見て取ることができました。
effective_cache_sizeは、SQL parse & planning & executionのプランニングにも関係しているのですね。
checkpoint_segmentsはデフォルトのままだったような気がします。。。
autovacuum_max_workersはvacuum処理が走りやすい更新系があるのであれば最低限意識しておく必要がありそうです。
wal_buffersは、見直しておきたい項目です。バッチでの更新処理がたっぷり動いているため気になります。
effective_cache_sizeはかなり大きい値を適用するのでしょうか。

チューニングの勘所を知る

目的別ガイド：チューニング編 | Let's Postgres
チューニングの概要が記載されています。概要であるため詳しい情報一つもありませんが、勘所を知るという意味で見ておくべきページだと私は考えました。目的別でまとめられてい点は見やすくてよかったです。

実際のパラメータ値算出

http://php.y-110.net/wiki/index.php?PostgreSQL%A1%A7%A5%C1%A5%E5%A1%BC%A5%CB%A5%F3%A5%B0%B4%AA%BD%EA
Stray Penguin - Linux Memo (PostgreSQL-5)
http://doruby.kbmj.com/o2_Ruby_On_Rails/20090916/PostgreSQL_8.3___postgresql.conf__
上記ページを参考にしつつ、現在運用している中小規模なシステム（ただしバッチ処理あり）への適用を想定しつつパラメータを考えてみたいと思います。

max_connectionsは少なくて良いかも

システムの性質上、実際にはそれほど多くのDB接続があるわけではないので、この値は抑えめにします。実際、100で運用していてもpsコマンドでプロセスを見た際にidleになっているものが多数ありました。

work_memは提案通りでいこう

コネクション数を減らすためメモリにも余裕ができるので、2048 (2MB) から 4096 (4MB)まで拡張できそうです。

エラーメッセージベースで記述されている

"PostgreSQLのトラブルシュートとチューニング | Let's Postgres"
トラブルシューティング的な内容ではあるもの、チューニングが必要になるタイミングは確かに困ったとき、という点には非常に納得出来るため一通り目を通しておいて損はないページだと思います。