この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
こんにちは marumoruです。
一部で（自分の周りのみ？）賑わっているPostgres8.3
気が付いたら、Postgres8.1系で止まっていた自分がいましたので
バージョンアップしてみました。
その時の8.1系との性能比較調査を報告しますー。
検証項目
１．pgbenchを使ったtps値比較
２．pgbenchを使ったHOT機能の動作調査
検証端末
OS:Linux Debian
CPU:Pentium4 2.6GHz
メモリ：1GHz
前提
スケーリングファクターを25で設定（250万件のデータ数）
各結果値については、それぞれの条件で10回行い、その平均値を算出
tps値（※）については、including connections establishing の値を取得
設定ファイルについては、ほぼデフォルト値を使用する。 テスト１（pgbenchを使ったtps値比較）
①クライアント数によるtpsの変化調査
pgbench -c XX -t 100 -s 25 pgbench_test
XXの数値を 1～100までのtps値の結果を測定
結果値
c値 postgres 8.1.4 postgres 8.3.1
1 228.6493 243.420941
10 140.781838 236.452233
50 112.203988 151.948232
100 106.594831 129.845791
★8.1より明らかにtps値が高く
クライアント値に伴っての値の下がり幅が低いのが分かります。
②トランザクション数によるtpsの変化調査
pgbench -c 10 -t XX -s 25 pgbench_test
XXの数値を 10～1000までのtps値の結果を測定
結果値
t値 postgres 8.1.4 postgres 8.3.1
10 452.462072 368.715249
100 151.04483 328.353416
500 112.203988 202.543517
1000 104.065397 165.649611
★クライアント値の場合と同様に
トランザクション値に伴う下がり幅が低いことが分かります。
このことから、負荷が上がった場合のふんばり具合が向上しているのかな
テスト２（pgbenchを使ったHOT機能の動作調査）
各バージョン毎にpgbenchを実行し、そのデータサイズの結果を取得
①8.1.4
調査用のデータベースを作成し、以下のpgbenchを実行
pgbench -i -s 10 hot_test
データ投入直後のデータサイズ
accounts テーブル
SELECT pg_size_pretty(pg_relation_size(‘accounts’));
pg_size_pretty
—————-
128 MB
PostgreSQLの物理的なテーブルサイズと有効・無効領域を調べる
SELECT * FROM pgstattuple(‘accounts’);
-[ RECORD 1 ]——+———-
dead_tuple_percent | 0 <– 不要領域
下のコマンドより、データ更新を行う
pgbench -c 10 -t 10000 hot_test
データ更新後のデータサイズ
accounts テーブル
SELECT pg_size_pretty(pg_relation_size(‘accounts’));
pg_size_pretty
—————-
141 MB <– 13MB増加
PostgreSQLの物理的なテーブルサイズと有効・無効領域を調べる
SELECT * FROM pgstattuple(‘accounts’);
-[ RECORD 1 ]——+———-
dead_tuple_percent | 8.66 <– 不要領域
②8.3.1
8.1.4と同様に調査用のデータベースを作成し、以下のpgbenchを実行
pgbench -i -s 10 -F 90 hot_test
（ ※ FILLFACTORを「90」に設定）
データ投入直後のデータサイズ
accounts テーブル
SELECT pg_size_pretty(pg_relation_size(‘accounts’));
pg_size_pretty
—————-
137 MB
PostgreSQLの物理的なテーブルサイズと有効・無効領域を調べる
SELECT * FROM pgstattuple(‘accounts’);
-[ RECORD 1 ]——+———-
dead_tuple_percent | 0 <– 不要領域
以下のコマンドより、データ更新
pgbench -c 10 -t 10000 hot_test
データ更新後のデータサイズ
accounts テーブル
SELECT pg_size_pretty(pg_relation_size(‘accounts’));
pg_size_pretty
—————-
137 MB <– 増減なし
PostgreSQLの物理的なテーブルサイズと有効・無効領域を調べる
SELECT * FROM pgstattuple(‘accounts’);
-[ RECORD 1 ]——+———-
dead_tuple_percent | 1.48 <– 不要領域
★FILLFACTORの設定により初期時のデータサイズは、8.3.1の方が高い
結果となっていますが、更新後のデータサイズが、8.3.1では増減がないことが分かる。不要領域についても数値を見れば明らかな結果ですね。
すげー8.3
