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 |
- 謎だ、共有バッファだけいじった状態が最もパフォーマンスアップに貢献している。
- やればやるほどひどくなっているし。