読者です 読者をやめる 読者になる 読者になる

アルパカDiary Pro

はてなブログProではありません

Postgres8.4のベンチマークを取ってみた その2

Postgres

前回いろいろ腑に落ちなかったので再度行いました。
今回考慮したのは以下の項目です。

pgbenchを行うperlスクリプト

再実行が面倒だったので作ってみました。
githubあげ。詳細はREADME参照。
http://github.com/toritori0318/perl-script/tree/master


bench?のYAMLがわかりずらいかもしれないので補足。
例えば以下のような設定の場合。

bench3:
  test_loop: 5
  repeat_interval: 3
  client: 10
  client_interval: 20
  transaction: 100
  transaction_interval: 200

実行計画は以下の通り。


repeat_intevalの数だけ繰り返し、
client_interval(またはtransaction_interval)の値だけ増やしていく、という感じです。

ハード環境(仮想サーバ上のLinux

CPU Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (これの2コアを使用)
メモリ 1024MB
OS CentOS 5

バージョン毎の共通手順

これは前回とほぼ一緒。
スケールを「25」→「30」に増やしたくらいです。

postgresql.confの設定

今回考慮した項目。すべてのバージョンで同じ値にしました。
基本的なところは調整したつもりです。

shared_buffers 128MB
max_connections 100
deadlock_timeout 1s
effective_cache_size 32M
work_mem 1MB
wal_buffers 64kB
wal_sync_method fsync
commit_delay 0
checkpoint_segments 12
random_page_cost 4.0
max_fsm_pages 20000
autovacuum off

テスト結果

ベンチ4(SELECTのみ)のクライアント数とトランザクション数を
前回より多めにしています。


ベンチ1(1クライアントあたりのトランザクション数を100で固定し、クライアント数のみ増加)
client:transaction

- 10:100 50:100 90:100
8.4.0 373.22 228.36 235.66
8.3.7 347.36 222.18 122.88
8.2.13 387.14 255.72 128.24
8.1.17 321.52 184.32 122.88
8.0.21 318.06 140.6 104.58
7.4.25 362.76 168.62 109.2


ベンチ2(クライアント数を1で固定し、1クライアントあたりのトランザクション数を増加)
client:transaction

- 1:1000 1:3000 1:5000
8.4.0 374.76 221.38 234.36
8.3.7 119.78 114.5 118.2
8.2.13 85.7 138.98 117.9
8.1.17 95.54 113.54 106.6
8.0.21 104.8 88.68 88.64
7.4.25 89 126.02 101.64


ベンチ3(クライアント数・1クライアントあたりのトランザクション数の双方を増加)
client:transaction

- 10:100 30:300 50:500
8.4.0 187.8 281.7 243.08
8.3.7 112.26 127.4 139.38
8.2.13 141.26 124.64 110.3
8.1.17 137.12 116.56 101.68
8.0.21 102.6 97.24 95.02
7.4.25 187.78 114.24 98.12


ベンチ4(検索のみ:クライアント数・1クライアントあたりのトランザクション数の双方を増加)
client:transaction

- 30:500 60:1000 90:1500
8.4.0 346.02 3644.2 6310.9
8.3.7 182.8 768.5 5399.74
8.2.13 288.24 965.82 1500.72
8.1.17 391.84 1487.52 3973.86
8.0.21 369.38 1468.76 3569.66
7.4.25 400.88 2134.62 3999.32


ベンチ4_2(検索のみ:createdb直後:クライアント数・1クライアントあたりのトランザクション数の双方を増加)
client:transaction

- 30:500 60:1000 90:1500
8.4.0 2550.2 6225.9 6890.42
8.3.7 2262.68 3888.52 6276.88
8.2.13 2403.96 3336.76 5644.3
8.1.17 2224.6 4491.62 5409.5
8.0.21 1713.9 2767.04 4696.74
7.4.25 1975.74 3696.92 4588.62

よくよく見てみると、ベンチマークが進むにつれて
DBが劣化していくのがわかると思います。
ベンチ1とベンチ3の1回目は同じ条件なのに、明らかに劣化してます。
さらにベンチ4(SELECTのみ)もパフォーマンスが落ちてしまってます。
これ一回毎にやり直した方がよかったかな…


ベンチ1−3の参照/更新のベンチマークですが、
これが本当なら8.4圧倒的なんですけど!
約2倍って、かなりのパフォーマンスですね。*1


SELECTに関しては、CREATEDBした直後のベンチマークも追加してみました。
バージョンが最新に近いほど、負荷耐性も良い事がわかりますね。


8.4がもう少しバージョンアップしたら
うちの本番DBに突っ込みたいなー

*1:というか、8.4は「劣化に強い」ということかも?