Postgres8.4のベンチマークを取ってみた その2
前回いろいろ腑に落ちなかったので再度行いました。
今回考慮したのは以下の項目です。
- テスト用スクリプト作成
- マルチコアでテスト
- postgresql.confのパラメータを合わせる
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
実行計画は以下の通り。
- 同じテストは5回繰り返す。
- ベンチマークの開始はクライアント(cl)=10、トランザクション(tr)100
- repeat_interval=3なので、間隔を変えて3回行う。
- ベンチマークの流れ
- (cl=10/tr=100)×5 → (cl=30/tr=300)×5 → (cl=50/tr=500)×5
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は「劣化に強い」ということかも?