PostgreSQL8.0.3のチューニング

cutxout2005-08-21

Server Spec

CPU Celeron 333MHz
RAM 128MB
HDD ad0: 38154MB [77520/16/63] at ata0-master UDMA33
OS FreeBSD 4.11-STABLE #0: Mon Aug 8 03:28:36 JST 2005
PostgreSQL 8.0.3

テスト項目

ベンチマーク

  • 他のプロセスの影響を排除するため、下記の条件とする。
  • 下記コマンドラインを、三回ずつ測定した平均値。
 /usr/local/bin/pgbench -c 1 -t 10 bench
 /usr/local/bin/pgbench -c 2 -t 10 bench
 /usr/local/bin/pgbench -c 4 -t 10 bench
 /usr/local/bin/pgbench -c 8 -t 10 bench
 /usr/local/bin/pgbench -c 16 -t 10 bench
 /usr/local/bin/pgbench -c 32 -t 10 bench
 /usr/local/bin/pgbench -c 64 -t 10 bench
 /usr/local/bin/pgbench -c 128 -t 10 bench
  • と思ったら、-c 128は実施できませんでした。orz
 starting vacuum...end.
 Connection to database 'bench' failed.
 FATAL:  sorry, too many clients already

設定値

  • デフォルト
  • 共有バッファ
    • 資料では16,000ページ(128MB)に設定しているが、全体で128MBしかないマシンなのでそれは無理。
    • 無駄に多く設定してシステムがスワップしてしまったら意味がないので、控えめに1,500ページ(12MB)位にしてみよう。
    • 2,000にしたら、起動してくれなかった。orz
 shared_buffers = 1500
  • トランザクションログバッファ
    • あまり根拠はないですが、資料で例示されていた32ページ(256KB)位にしてみよう。
 wal_buffers = 32
  • ライタープロセス
    • たいしたトランザクションが生じるわけではないけど、マシン全体のパフォーマンスが低いので、CHECKPOINTがあまり発生しなくなるのはよいことだ。
    • 資料の通り、200ms毎に最大4ページの設定にしてみる。
 bgwriter_delay = 200
 bgwriter_maxpages = 4
  • テーブルスペース
    • HDD一個しかないし、専用のパーティションを作れるわけでもないので、実施不可能。
  • チェックポイントセグメント数
    • 根拠はないが、資料の通りで16セグメントにしてみる。
 checkpoint_segments = 16

結果

Client 1 2 4 8 16 32 64
Default 31.8 38.3 34.8 35.0 34.4 26.0 19.1
shared_buffers = 1500 44.8 46.1 47.9 46.5 31.9 28.9 17.0
wal_buffers = 32 27.3 42.3 41.9 38.4 33.3 24.2 20.4
bgwriter_maxpages = 4 36.9 33.1 30.8 42.1 29.5 30.9 13.0
checkpoint_segments = 16 33.1 28.2 38.6 34.2 24.9 23.4 17.7
  • 謎だ、共有バッファだけいじった状態が最もパフォーマンスアップに貢献している。
  • やればやるほどひどくなっているし。