OSDL DBT-1によるPostgreSQLのVACUUMに関する考察 || OSS iPedia

OSDL DBT-1によるPostgreSQLのVACUUMに関する考察

【1.概要】

　PostgreSQLを運用する上で，バキュームは欠かすことができない。しかし、業務サービスを停止する時間が限られてしまう場合や、データベースのデータサイズが大きい場合、バキュームを効率的に実行することが求められる。ここでは、DBT1を長時間運転させることによるBT値の劣化の度合いや、BT値を維持させるために効率的なバキュームの運用方法を検討する。

【2.測定結果】

　PostgreSQL8.0，PostgreSQL8.1のそれぞれを表2-1の条件（ケース）で，DBT1を実行させたBT値を図2-1に示す。

表2-1 DBT1を長時間実行させる条件
測定ケース名	DBT1のrun_duration指定値	VACUUMの実行の有無
CASE1	4100(1.14Hr)	無
CASE2	12600(3.5Hr)
CASE3	25200(7.0Hr)
CASE4	36000(10.0Hr)

図2-1．DBT1を長時間運転させることによるBT値の劣化

　DBT1の実行に比例してBT値が劣化していることがわかる。
　次に、表2-2に、一旦DBT1を終了させ、VACUUMを実行した時の時間の関係を示す。

表2-2 DBT1を実行し停止後のVACUUMの実行時間
VACCUM実行条件	VACUUMの対象テーブル	実行時間(秒）
VACCUM実行条件	VACUUMの対象テーブル	v.8.0.6	v.8.1.2
CASE2の終了後に実行	itemテーブルのみ	38.801	2.445
同上	全テーブル	861.791	382.127

【3.考察】

3.1 効率的なVACUUM運用案

　測定結果から，VACUUMコマンドの実行時間は，全テーブル対象の場合でPostgreSQL 8.0.6で861秒， PostgreSQL 8.1.2で382秒を要することが分った。DBT1を特定業務に見立てると，24時間の連続運転の必要がなければ，計画停止後にVACUUMを行えばよいことになる。しかし，24時間連続運転が必要だったり，停止時間が限られる場合，表3-1に示すように，業務実行中にVACUUMを実行する方法もその対応策と考え，実現性をDBT-1を用いて検証した。全テーブルをVACUUMするケース，無効領域の発生しているテーブルの中で最もアクセス頻度の高いitemテーブルのみをVACUUMするケース，無効領域が最も大きいcustomerテーブルのみをVACUUMするケースを追加測定し，BT値を比較した。

表3-1 DBT1の高可用性を考慮したVACUUM運用の対策案
測定ケース名	run_duration	VACUUMの運用方法
CASE5	run_duration	36000(10.0Hr)	参照頻度の高いitemテーブルのみを3.5Hr経過後，7Hr経過後にVACUUMを実行
CASE6	36000(10.0Hr)	全テーブルを3.5Hr経過後，7Hr経過後にVACUUMを実行
CASE7	36000(10.0Hr)	無効領域の成長度が大きいcustomerテーブルのみを3.5Hr経過後，7Hr経過後にVACUUMを実行

　表3-1の対策案を,いままでの長時間DBT1を実行させたケースと比較を図3-1に示す。

図3-1．DBT1実行中にVACUUMを実行したケースとVACUUMしないままDBT1を実行したケースとの比較

　VACUUMの実行時間は，DBT-1実行中に実行したケースとDBT-１終了後に実行したケースを比べると，3〜4倍の差がある。全テーブルのVACUUMは，PostgreSQL 8.0.6で約60分，PostgreSQL 8.1.2で約20分要しているが，item テーブル単独のVACUUMは，PostgreSQL 8.0.6で40秒，PostgreSQL 8.1.2では10秒以内に終了しており，システムに掛かる負荷，ユーザ応答時間に対する影響は比較的小さいと判断する。
　以上のことから，対象テーブルを絞り業務中にVACUUMすることで，BT値の劣化防止に効果を上げることができると考える。

このデータの性能データ

関連する性能データは登録されていません。

OSS iPedia