■現象
InterScan MSS 7.x が使用するデータベースのデータサイズが異常に増大し、このデータベースのデータサイズの肥大化が際限なく進み、/var の領域またはハードディスク全体の領域を使用し、空き領域が無くなることで、メール配送を止めるなどの現象が環境によって発生する可能性がございます。
InterScan MSS が使用する PostgreSQL はデータ追記型のデータベースであるため、メンテナンス処理を実施しない場合、データベースに格納されたデータによってハードディスク領域が消費されていきます。
■対象製品
InterScan MSS 7.0 Linux版
InterScan MSS 7.0 Solaris版
InterScan MSS 7.1 Linux版
■原因
(1) InterScan MSS 7.0 Service Pack 1 Patch 1 未満の環境をご利用のお客様
InterScan MSS 7.0 は、パターンファイルやエンジンが保存されている pg_largeobject テーブル (コンポーネントのアップデートが行われる毎に、このテーブルは更新されます)に対してメンテナンス処理を実施していませんでした。
このため、パターンファイルやエンジンのアップデートが行われるたびに、pg_largeobjectのサイズが線形に増加していました。
(2) InterScan MSS 7.0 Service Pack 1 Patch 1 以降ならびに、InterScan MSS 7.1 の環境をご利用のお客様
InterScan MSS 7.0 Service Pack1 Patch1 以降、InterScan MSS 7.1では、pg_largeobjectを含む特定のテーブルに対して、午前2時にANALYZEを、午前3時にVACUUMを実施するようになり、不要領域の再利用ができるようになりました。
しかし、メッセージ量の多い環境などでは、Free Space Map (以下、FSM) のサイズが要因となり、肥大化する場合がございます。
これは、PostgreSQLが、VACUUM実行時に削除されて不要となった領域をFSMに登録して、領域の再利用を行います。
そのため、FSMのサイズが削除されて不要となった領域全てを記録するのに十分でない場合、未使用の領域が有効に活用されず、テーブルが肥大化します。
■ 現象の確認方法
(例) データサイズが約10GBの場合
| #du -sk /var/imss 10403780 /var/imss |
特定のoidのファイルで、約1GBのものが多数存在します。
(例) データベースoid=16385、オブジェクトoid=2613のファイル
| # find /var/imss –size +1000000k /var/imss/pgdata/base/16385/2613.1 /var/imss/pgdata/base/16385/2613 /var/imss/pgdata/base/16385/2613.4 /var/imss/pgdata/base/16385/2613.3 /var/imss/pgdata/base/16385/2613.7 /var/imss/pgdata/base/16385/2613.5 /var/imss/pgdata/base/16385/2613.6 /var/imss/pgdata/base/16385/2613.2 /var/imss/pgdata/base/16385/2613.8 |
該当のデータベースおよびオブジェクトは、imssデータベースのpg_largeobjectテーブルである事が確認できます。
(例) データベースoid=16385、オブジェクトoid=2613の場合
| # /opt/trend/imss/PostgreSQL/bin/psql imss sa imss=# select oid, datname from pg_database where oid = 16385; oid | datname -------+----------- 16385 | imss (1 row) imss=# select oid, relname from pg_class where oid = 2613; oid | relname ------+---------------- 2613 | pg_largeobject (1 row) |
■解決方法
(1) InterScan MSS 7.0 Service Pack 1 Patch 1 未満の環境をご利用のお客様
Service Pack1 Patch1以降を適用してください。適用後にはVACUUMが実施され不要領域の再利用が開始されます。
合わせて、VACUUM FULL または、データベースのバックアップ/復元を実施して、不要領域を削除し、ディスク領域を開放してください。
テーブルが異常に肥大化した状態でVACUUM FULLを実施した場合、処理が完了するまでに非常に時間がかかる可能性があります。処理が完了するまでのあいだ、コンポーネントのアップデートが行われないため、セキュリティリスクを懸念される場合には、VACUUM FULLの代わりに、メールサービスを停止した上で、データベースのバックアップ/復元を実施してください。
(2) InterScan MSS 7.0 Service Pack 1 Patch 1 以降ならびに、InterScan MSS 7.1 の環境をご利用のお客様
例えば、max_fsm_pages の値を 200000 程度に引き上げることで、テーブルサイズの肥大化を防止できる場合があります。
※ max_fsm_pages では、1 page あたり、6 bytes の共有メモリを消費します。
※ max_fsm_pages の値につきましては、弊社で推奨する値はございません。お客様の環境に合わせ て値を変更してください。
FSM に関しましては、こちら (JP-2063581) も合わせてご参照ください。
また、「pg_largeobject」 のテーブルサイズを監視して、定期的に VACUUM FULL を実施してください。
■VACUUM FULLの実施方法
方法1または、2で、VACUUM FULLを定期的に実行して、不要領域を開放してください。
注意：
VACUUM FULLはテーブルをロックするため、安全のためにVACUUM FULLを実施する場合は、
予約アップデートを無効にすることを推奨します。
方法1：
次の方法で VACUUM FULL ツール（vacuum_pglargeobj.sh）を入手いただけます。
| InterScan MSS 7.0 Linux 版 | Service Pack 1 Patch 3 に含まれています。 (機能5) |
| InterScan MSS 7.0 Solaris 版 | Service Pack 1 Patch 2 以降に含まれています。（Patch 2： 機能6） |
| InterScan MSS 7.1 Linux 版 | Patch 1 以降に含まれています。（機能4） |
方法2：
手動でpg_largeobjectテーブルにVACUUM FULLを実行する方法
・psqlコンソールから行う場合
|
imss=# vacuum full pg_largeobject; |
・コマンドラインから行う場合
|
# /opt/trend/imss/PostgreSQL/bin/vacuumdb -f -t pg_largeobject -U sa imss |
なお、VACUUM実行時にmax_fsm_pages や max_fsm_relations に関するメッセージが出力される場合はこちらを参考に対処を行ってください。
■データベースのバックアップ/復元方法
※ PostgreSQL のサービスが起動している必要があります
※ 以下の例では、バックアップしたファイル (ダンプ) を作業ディレクトリに作成しますので、作業ディ レクトリに十分な空き容量が必要です
1. InterScan MSS 関連サービスの停止をいたします。
|
# <install dir>/script/S99ADMINUI stop |
2. 以下のコマンドでデータベースのバックアップを取得します。
|
# /opt/trend/imss/PostgreSQL/bin/pg_dump -U sa imss > imss_dump.sql |
なお、十分な空き容量が無い場合は、以下のようにダンプを bzip2 や gzip で圧縮すれば、バックアップのファイルサイズは小さくて済みます。
※処理時間は長くなります
|
# /opt/trend/imss/PostgreSQL/bin/pg_dump -U sa imss | bzip2 > imss_dump.sql.bz |
3. いったんデータベース 「imss」 を削除し、新たに作成し、データベースの言語を設定します。
|
# /opt/trend/imss/PostgreSQL/bin/dropdb -U sa imss |
4. 手順2 で取得したバックアップを復元します。
|
# /opt/trend/imss/PostgreSQL/bin/psql -U sa imss < imss_dump.sql |
手順2でダンプを圧縮した場合には、以下のコマンドを使用します。
|
# bunzip2 -c imss_dump.sql.bz | /opt/trend/imss/PostgreSQL/bin/psql -U sa imss |
5. 手順1 で停止したサービスを順に開始します。
|
# <install dir>/script/S99MANAGER start |
■ FSM の変更方法
1. /var/imss/pgdata/postgresql.conf を任意のエディタで開き、以下のようにパラメータに任意の値を設定します。
※ 編集前に必ずバックアップを取得してください
|
postgresql.conf |
2. 以下のコマンドで PostgreSQL を再起動します。
|
# /opt/trend/imss/script/dbctl.sh restart |
■寄せられる質問
Q1. /var 領域を確認する理由を教えてください。
A1. /var ディレクトリはサイズが変更されるデータを格納するディレクトリでスプールディレクトリやファイル、管理やログデータ、一時的なファイルを格納しています。そのためInterScan MSSの運用に限らず、定期的にサイズを確認することを推奨いたします。
Q2. 以前の製品Q&Aのタイトルとタイトルが変わった理由を教えてください。
A2. 旧タイトルである「UNIX：PostgreSQLデータベースのデータサイズが異常に増大します」では、わかりにくいため変更いたしました。
Q3. 不要領域がないはずですが、 pg_largeobject のサイズが微増しています。理由を教えてください。
A3. 日々の新しい脅威に対応するため、パターンファイルのサイズや、検索エンジンのサイズが日々増加する傾向にあります。そのため、不要領域が存在しなくても、 pg_largeobject のサイズが微増いたします。現在のパターンファイル、検索エンジンのサイズの増加傾向から、 pg_largeobject のサイズが数 GB となるようなことはございません。
