DoRuby

Postgres8_3⇔8_1の性能比較してみました

アピリッツ広報担当

作成: 2008.04.21 更新: 2021.03.05

この記事はアピリッツの技術ブログ「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