日々の記録別館

2012-01-19

pgbenchでUNLOGGEDの効果を再確認（接続数=1)

測定環境/方式の変更

前回の検証結果が微妙だったので、永安様のコメント(shared_buffersの増加)と、autovacuum=offの設定を追加して、再度pgbenchの通常テーブル版とUNLOGGEDテーブル版の差異を確認してみた。

shared_buffers	2GB
checkpoint_segments	100
autovacuum	off

また、同時接続数を1に絞って、競合を省いた状態で測定してみる。これが通常/UNLOGGEDテーブルでの基本的な差になるはず。

scale factor	100
connect	1
duration	600
その他	デフォルト

測定自体は1回勝負で。

測定結果(tps)

	FILLFACTOR設定(100%）	FILLFACTOR設定(80%）
通常テーブル版	395.016214	439.500559
UNLOGGED版	526.332513	585.762816

お、なんかそれっぽい結果になっている。
FILLFACTORが100%の場合も80%の場合も、通常テーブル版のtpsをベースにするとUNLOGGED版はだいたい30%程度の向上効果があるという結果になった。

測定結果(latencies)

処理＼実行設定	通常/FF=100	通常/FF=80	UL/FF=100	UL/FF=80
BEGIN	0.046743	0.044011	0.034662	0.038746
UPDATE accounts	0.196435	0.156118	0.468165	0.550434
SELECT abalance	0.123869	0.110331	0.100805	0.105568
UPDATE tellers	0.245281	0.217802	0.241394	0.240071
UPDATE branches	0.937295	0.494505	0.893534	0.598381
INSERT hinstory	0.109277	0.098475	0.087406	0.093225
END	0.835786	1.121117	0.045679	0.050481

これも予想どおりEND部分について、通常テーブル版とUNLOGGEDテーブル版ではっきりした差が見られる。

END(COMMIT)の背景でWALをファイルに書き出す処理の差が明確に出た結果になったと思う。
ただ、UPDATE accountsの処理が何故かUNLOGGEDのほうが時間がかかっている。ここが謎。

あとは、この環境で接続数を増やしてどういった傾向が見られるかを確認すればいいかな。接続数をどのくらい増やすと、WAL書き込み有無による差異がその他の競合により打ち消されていくのだろうか・・・？

Permalink | コメント(0) | トラックバック(0) | 14:50

トラックバック - http://d.hatena.ne.jp/nuko_yokohama/20120119/1326952206

リンク元