DenbunPOPの運用を始めると日ごとにメールデータがDenbunPOPのDB(PostgreSQL)に蓄積されDBのサイズが肥大化します。DBの肥大化はDenbunPOPの性能劣化の原因になります。これを防ぐには定期的にDBの保守作業を行う事が重要です。この資料ではDBの保守作業にかかる時間の計測結果を記します。

※ PostgreSQLでは更新や削除によってもDBが肥大化する場合があります
※ 保守コマンドの実行中はDenbunを使用出来なくなる保守コマンドがありますのでご注意ください

■目次
1.はじめに
2.計測に使用した環境
3.計測結果
4.計測結果の見かた
5.DBの保守時間を短縮させる方法について
6.最後に

DBの保守作業で使用する保守コマンドの実行例と概要を説明します。

(ア) VACUUM (不要領域回収１)
【実行例】
% vacuumdb -v -z -d dnpwmldb -U postgres
※コマンド実行中もDenbunを使用する事が可能です。
※不要になったデータが占有している領域を再利用可能な状態にします。

(イ) VACUUM FULL (不要領域回収２)
【実行例】
% vacuumdb -f -v -z -d dnpwmldb -U postgres
※コマンド実行中はDenbunを使用する事ができません。
※不要になったデータが占有している領域を切り詰めてディスクに保存し直します。

(ウ) REINDEX (インデックスの再構築)
【実行例】
% reindexdb -d dnpwmldb -U postgres
※コマンド実行中はDenbunを使用する事ができません。

(エ) BACKUP (データベースのバックアップ)
【実行例】
% pg_dump -b -Fc -U postgres dnpwmldb > dnpwmldb.pgdmp
※コマンド実行中もDenbunを使用する事が可能です。

(オ) RESTORE (バックアップからの復元)
【実行例】
% dropdb -U postgres dnpwmldb
% pg_restore -C -Fc -U postgres -d template1 ./dnpwmldb.pgdmp
% psql -U postgres -d dnpwmldb < ｲﾝｽﾄｰﾙ先(*1)/admintools/sql/uninstall_textsearch_ja.sql
% psql -U postgres -d dnpwmldb < ｲﾝｽﾄｰﾙ先(*1)/admintools/sql/textsearch_ja.sql
% psql -U postgres -d dnpwmldb < ｲﾝｽﾄｰﾙ先(*1)/admintools/sql/denbun_ja.sql
※ｲﾝｽﾄｰﾙ先(*1)はDenbunPOPのインストール先。 例) /var/www/cgi-bin/dnpwml
※コマンド実行中はDenbunを使用する事ができません。

使用した機材

PC	HP DL120 G6 X3430 Pluggable SATA JP Svr
CPU	Intel(R) Xeon(R) CPU X3430 @ 2.40GHz (4Core)
Memory	PC3-10600 2GB × 4
Disk	300G 15K SAS 3.5 DP (6.0Gbps) × 2
RAID	RAID 0 HP P212/ZM SMART ARRAY CONTROLLER HP 256MB P-SERIES CACHE MODULE

構成

OS	CentOS 5.6 (i386)
PostgreSQL	8.3.5
Denbun POP	V3.0 R1.1

設定

共有メモリ	kernel.shmall = 2147483648 kernel.shmmax = 2147483648 ※/sys/sysctl.conf内のパラメータを設定
PostgreSQL	shared_buffers = 1638MB max_connections = 500 ※postgresql.conf内のパラメータを設定

保守コマンドが完了するまでにかかった時間の計測結果と、「VACUUM FULL」と「REINDEX」実行後に計測したDenbunの応答時間の計測結果を以下に記します。

表1：各種保守コマンドが完了するまでにかかった時間 (時:分:秒)

保守コマンド	10 GB	50 GB	100 GB
VACUUM (*1)	0:11:10	0:32:44	0:57:11
VACUUM FULL (*1)	0:29:25	1:19:50	5:05:43
REINDEX (*1)	0:15:01	1:53:39	3:55:42
BACKUP	1:01:18	5:16:56	9:19:54
RESTORE	0:50:13	4:39:17	9:20:08

メールデータ(10GB,50GB,100GB)はDBに格納されているメール全件の総サイズです。
DB(/var/pgsql/data)のディスク上のサイズは、10GBの時21GB、50GBの時103GB、100GBの時208GBでした。

メールは2,345B〜22,948Bのメール16パターンを複製して作成。
メール1件当たりの平均サイズは約8KBです。
DBには、1ユーザーあたり168,160件 (約1GB) のメールを格納しています。
※168,160件 ≒ (1日の送受信件数) 60件 × (10年間の稼働日数) 2400日

(*1) 「VACUUM」、「VACUUM FULL」、「REINDEX」に関しては保守コマンドを実行する前にDBに対してメールを1GB削除し、1GB追加した後に保守コマンドを実行しています。追加、更新、削除された量やレコード数に応じて保守コマンドの実行時間が延びますのでご注意ください。

表1を見るとメールデータの増加にともない保守コマンドが完了するまでの時間が延びている事が分かります。
「VACUUM」を週1回実行し、「VACUUM FULL」と「REINDEX」を月1回実行する例で考えると、それぞれの保守作業の予想時間は以下のようになります。
※1カ月間のデータの更新量が1GB未満である事を前提にしています。

表2：メールデータが50GBの場合の保守作業の予想時間

週の保守作業の予想時間
保守作業 (VACUUM) にかかる時間	約30分
Denbunを使用できない時間	なし(*1)
月の保守作業の予想時間
保守作業 (VACUUM FULL + REINDEX) にかかる時間	約3時間
Denbunを使用できない時間	約3時間

表3：メールデータが100GBの場合の保守作業の予想時間

週の保守作業の予想時間
保守作業 (VACUUM) にかかる時間	約60分
Denbunを使用できない時間	なし(*1)
月の保守作業の予想時間
保守作業 (VACUUM FULL + REINDEX) にかかる時間	約9時間
Denbunを使用できない時間	約9時間

(*1) サーバーに負荷がかかった状態ですので、Denbunのレスポンスは低下します。

上記の予想時間は、サーバーのスペック、負荷状態、メールの質(添付有無など)、メールの総量(サイズ、件数)、データの更新量(未読⇒既読、削除など)によっても変わってきますのでご注意ください。

上記に加えDBのバックアップを行う場合は、BACKUPコマンドの実行時間も保守作業に必要な時間として見積もっておく必要があります。pg_dumpコマンドによるバックアップを行う場合はバックアップ中もDenbunにアクセスする事が可能です。

通常の保守作業ではDenbunを使用できなくなる時間が長くなってしまい、運用上問題がある場合には以下の方法で保守時間を短縮し、通常の(時間がかかる)保守作業の頻度を抑える事をご検討ください。
例えば、日、週、月ごとに行う保守作業ではここで紹介する保守作業を行い、半年に1回は通常の(時間がかかる)保守作業を行う等の運用をご検討ください。

保守作業時間を短縮するには、以下の方法が考えられます。
(ア) VACUUM (FULL)とREINDEXを行う際、更新頻度が高いテーブルのみに行う
(イ) BACKUPする際、pg_dump以外の方法でバックアップを行う
それぞれの方法については以下で説明します。

(ア) VACUUM (FULL)とREINDEXを行う際、更新頻度が高いテーブルのみに行う
更新頻度が高く、Denbunの性能に直結するテーブルは、以下の通りです。
データベース名: dnpwmldb

表4：上記の7テーブルのみに対して行った保守コマンドの実行時間 (時:分:秒)

保守コマンド	(全テーブルに実行した時) 50GB	(7テーブルに実行した時) 50GB
VACUUM	0:32:44	0:22:35
VACUUM FULL	1:19:50	0:50:44
REINDEX	1:53:39	1:22:07

※保守コマンドを実行する前にDBに対してメールを1GB削除し、1GB追加した後に保守コマンドを実行しています。

表1と表4を比較するとDB全体に対して実行した場合より、更新頻度の高いテーブルに絞って保守コマンドを実行した場合の方が時間を短縮できる事がわかります。

メールデータが50GBの例では、VACUUMの時間は32％短縮、 VACUUM FULLの時間は37％短縮、REINDEXの時間は28％短縮できました。
ただし、DB全体に対して保守コマンドを実行していませんので、更新や削除の際に生じた不要領域が残っている事にご注意ください。

保守コマンドの実行例

● VACUUM の実行例
% vacuumdb -v -z -d dnpwmldb -U postgres -t [テーブル名]
※複数のテーブルを纏めて実行できませんので1テーブルずつ実行してください

● VACUUM FULL の実行例
% vacuumdb -f -v -z -d dnpwmldb -U postgres -t [テーブル名]
※複数のテーブルを纏めて実行できませんので1テーブルずつ実行してください

● REINDEXの実行例
% reindexdb -d dnpwmldb -U postgres -t [テーブル名]
※複数のテーブルを纏めて実行できませんので1テーブルずつ実行してください


(イ) BACKUPする際、pg_dump以外の方法でバックアップを行う
簡単な方法としては、DB(PostgreSQL)停止後、DBのデータ領域(ディレクトリ)をコピーする方法があります。
DBを停止させて行う必要がありますので、バックアップ中はDenbunへのアクセスが出来ませんがpg_dumpより高速にバックアップを行う事ができます。
詳しくは、PostgreSQLのマニュアルを参照して下さい。

今回の計測では、保守コマンドによって回収されるべき不要領域を作成するために手作業でデータに変更を加えて計測を行っております。
しかし、実際の運用環境下では、さらに多伎多用なデータの更新がなされるはずです。従いまして、実際の運用環境下にて測定した場合には、保守コマンドが完了するまでの時間が多少長くなる可能性があります。