Postgres8.4のベンチマークを取ってみた その２
前回いろいろ腑に落ちなかったので再度行いました。
今回考慮したのは以下の項目です。
- テスト用スクリプト作成
- マルチコアでテスト
- 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
実行計画は以下の通り。
- 同じテストは５回繰り返す。
- ベンチマークの開始はクライアント(cl)＝10、トランザクション(tr)100
- repeat_interval＝３なので、間隔を変えて３回行う。
- ベンチマークの流れ
- (cl=10/tr=100)×５ → (cl=30/tr=300)×５ → (cl=50/tr=500)×５
repeat_intevalの数だけ繰り返し、
client_interval（またはtransaction_interval）の値だけ増やしていく、という感じです。
ハード環境（仮想サーバ上のLinux）
| CPU | Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz （これの２コアを使用） |
| メモリ | 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 |
テスト結果
ベンチ４（SELECTのみ）のクライアント数とトランザクション数を
前回より多めにしています。
ベンチ１（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 |
ベンチ２（クライアント数を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 |
ベンチ３（クライアント数・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 |
ベンチ４（検索のみ：クライアント数・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 |
ベンチ４＿２（検索のみ：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が劣化していくのがわかると思います。
ベンチ１とベンチ３の１回目は同じ条件なのに、明らかに劣化してます。
さらにベンチ４（SELECTのみ）もパフォーマンスが落ちてしまってます。
これ一回毎にやり直した方がよかったかな…
ベンチ１−３の参照／更新のベンチマークですが、
これが本当なら8.4圧倒的なんですけど！
約２倍って、かなりのパフォーマンスですね。*1
SELECTに関しては、CREATEDBした直後のベンチマークも追加してみました。
バージョンが最新に近いほど、負荷耐性も良い事がわかりますね。
8.4がもう少しバージョンアップしたら
うちの本番DBに突っ込みたいなー
*1:というか、8.4は「劣化に強い」ということかも？
