postgresql_チューニング

JITAKU_SVR_Wiki

shared_buffers †

推奨値：OS搭載メモリの10～20%(デフォルト32MB)
　 説明：メモリ上でデータ操作、読み込みを行うための領域
　 効果：HDDの速度が遅いため、メモリに役割を任せることにより、高速なデータのやり取りが可能
　　　　　ただし、値を大きくしてもOSのキャシュとぶつかるためあまり効果が出ない

checkpoint_segments †

推奨値：書き込みが多いシステムは32～256(デフォルト300秒)
　 説明：メモリ上に乗っているデータをHDDに書き込むタイミング
　　　　　1つ16MBの固まりが○個出来たらHDDへ書き込む。
　 効果：小さいほど高速になるが、ディスクアクセスが頻発する
　　　　　 また、checkpoint_timeoutが優先されるので、そちらの値も確認すること

checkpoint_timeout †

推奨値：checkpoint_segmentsより大きな値(デフォルト300)
　 説明：checkpoint作成のタイミングが規定値に達すると実行される
　 効果：特にパフォーマンスには影響しないが、checkpoint_segmentsより値が小さい場合、
　　　　　 先にcheckpointを作成されてしまう

wal_buffers †

推奨値：4MB以上(デフォルト-1)
　 説明：WALログ(REDOログ)のキャッシュサイズ
　　　　 データと同じでHDDに書き込む前にメモリ上で確保する領域
　　　　 値が小さ過ぎると頻繁にディスクアクセスが頻発してしまう
　 効果：ディスクアクセスが頻発するとパフォーマンス劣化につながってしまうので、
　　　　 最低4MB以上の値を与えることでパフォーマンス向上につながる

effective_cache_size †

推奨値：OS搭載メモリの50%程度(デフォルト128MB)
　 説明：ディスクキャッシュの実行サイズ
　　　　 データベース領域と同じサイズ以上を確保すれば、データベースをすべてメモリ内に入れられることになる。
　　　　 次項のrandum_page_costも合わせてチューニングすると尚良し
　 効果：index scanは共有バッファメモリを使用せす、effective_cacheをしようする
　　　　 つまり、この値が小さいとindexのサイズが大きいとキャッシュから溢れ、
　　　　 直接HDDとやり取りを行ってしまう

random_page_cost †

推奨値：2～3(デフォルト4)
　 説明：HDDからランダムにブロックを読み取るコスト
　 効果：より低くすることで、問い合わせオプティマイザが積極的にindex scanをするようになる

work_mem †

推奨値：(実メモリ - shared_buffers) / max_connections (デフォルト1MB)
　 説明：1プロセスごとに使用出来るメモリ量
　 効果：大きくすることで、1プロセスあたりのメモリ使用量が大きくなるために処理が速くなる
　　　　 特にsortを行う処理が多い場合などには有効