データストアのガベージコレクション

従来の WCM アセットを削除すると、データストアレコードの参照がノード階層から削除されますが、データストアレコード自体は削除されずに残ります。その結果、どこからも参照されることのないこのデータストアレコードは、不要な「ガベージ」として残ることになります。例えば、インスタンスにいくつかのガベージアセットが存在する場合、そのガベージアセットを削除すれば、領域を保護して、バックアップやファイルシステムのメンテナンスのパフォーマンスを最適化できます。

ほとんどの場合、WCM アプリケーションは、情報は収集しても、あまり頻繁に情報を削除しません。旧バージョンより優先する新しい画像が追加されたとしても、バージョン管理システムは、いつでも旧バージョンに戻せるように旧バージョンを残します。その結果、システムに追加されるコンテンツは、そのほとんどが永続的に保存されることになります。それでは、いったい何が原因でリポジトリ内に不要な「ガベージ」が生み出されるのでしょうか。

AEM では、以下に示す様々な内部アクティビティやハウスキーピングアクティビティのオブジェクトをリポジトリに保管します。

• ビルドおよびダウンロードされたパッケージ
• 公開レプリケーション用に作成された一時ファイル
• ワークフローのペイロード
• DAM レンダリング時に一時的に作成されたアセット

これらの一時オブジェクトがデータストア内の領域をある程度消費するほど大きく、しかもそのオブジェクトが最終的に使用されなかった場合は、そのデータストアレコード自体が「ガベージ」として残ります。標準的な WCM オーサー／パブリッシュアプリケーションの場合、このようなガベージが生まれる最大の原因は、一般的に、パブリッシュアクティベーションのプロセスにあります。データを発行に複製する場合、最初に「Durbo」と呼ばれる効率的なデータ形式でコレクションに収集し、/var/replication/dataの下のリポジトリに保存すると、データは発行されます。 データバンドルは通常、データストアの上限サイズを超えるので、最終的にデータストアレコードとして保存されます。レプリケーションが完了すると、/var/replication/data内のノードは削除されますが、データストアレコードは「ガベージ」のままです。

回収可能なガベージが生まれるもう 1 つの原因はパッケージです。他のデータもそうですが、パッケージデータもリポジトリ内に保存され、4 KB を超えるパッケージはデータストア内に保存されます。開発プロジェクトの工程やその後のシステムのメンテナンスでは、パッケージのビルドとリビルドが何度もおこなわれ、ビルドがおこなわれるたびに新しいデータストアレコードができて、以前のビルドのレコードは孤立します。

データストアのガベージコレクションの機能

リポジトリが外部データストアに設定されている場合、週別メンテナンスウィンドウの一部として、データストアのガベージコレクションは自動的に実行されます。システム管理者は、必要に応じて、データストアのガベージコレクションを手動で実行することもできます。 一般的に、データストアのガベージコレクションは定期的に実行することが推奨されますが、データストアのガベージコレクションを計画するときは、次の事項を考慮する必要があります。

• データストアのガベージコレクションは時間がかかり、パフォーマンスに影響する可能性があるので、適切に計画する必要があります。
• データストアのガベージレコードを削除しても通常のパフォーマンスに影響はないので、これはパフォーマンス最適化ではありません。
• ストレージの使用状況や、バックアップ時間などの関連要素に問題がない場合は、データストアのガベージコレクションを延期しても安全です。

データストアのガベージコレクターは最初に、プロセスを開始する際に現在のタイムスタンプを記録します。その後、マルチパスマーク／消去パターンアルゴリズムを使用してガベージコレクションが実行されます。

第 1 段階では、データストアのガベージコレクターは、すべてのリポジトリコンテンツを包括的に調べます。データストアレコードを参照する各コンテンツオブジェクトについて、データストアのガベージコレクターは、ファイルシステムからファイルを見つけてメタデータの更新を実行し、「最終変更日」または MTIME 属性を変更します。この時点で、この段階までにアクセスされたファイルは、当初のベースラインタイムスタンプより新しいものになります。

第 2 段階では、データストアのガベージコレクターは、「検索」とほとんど同じ方法で、データストアの物理的なディレクトリ構造を調べます。データストアのガベージコレクターは、ファイルの「最終変更日」または MTIME 属性を調べて、次の判断をおこないます。

• MTIME が当初のベースラインタイムスタンプより新しい場合、そのファイルは、第 1 段階で見つけたファイルか、ガベージコレクション処理中にリポジトリに追加されたまったく新しいファイルであるかのどちらかです。どちらの場合も、レコードはアクティブ状態になるので、ファイルは削除されません。
• MTIME が当初のベースラインタイムスタンプより古い場合、そのファイルはアクティブに参照されていないので、削除可能なガベージと見なされます。

この方法は、プライベートなデータストアを持つ単一のノードに適しています。ただし、データストアは共有されている場合があります。その場合、他のリポジトリからデータストアレコードへのアクティブなライブ参照はチェックされず、そのアクティブな参照ファイルが誤って削除される可能性があります。システム管理者はガベージコレクションを計画する前に、データストアが共有されていないかどうかを確認し、データストアが共有されていないことが明確な場合にのみ、シンプルな組み込みデータストアのガベージコレクションプロセスを使用するようにしてください。

データストアのガベージコレクションの実行

データストアのガベージコレクションは、AEM が実行されているデータストアのセットアップに応じて、3 つの方法で実行できます。

1. リビジョンのクリーンアップ経由 — 通常、ノードストアのクリーンアップに使用されるガベージコレクションメカニズム。

2. データストアのガベージコレクション - 外部データストア用のガベージコレクションメカニズムで、操作ダッシュボードで使用可能。

3. JMX コンソール。

TarMK がノードストアとデータストアの両方として使用されている場合は、その両方のガベージコレクションにリビジョンクリーンアップを使用できます。一方、ファイルシステムデータストアなど外部データストアが設定されている場合は、リビジョンクリーンアップとは別に、データストアのガベージコレクションを明示的に起動する必要があります。データストアのガベージコレクションは、操作ダッシュボードと JMX コンソールのどちらからでも起動できます。

次の表に、AEM 6 でサポートされているすべてのデータストアのデプロイメントで使用する必要がある、データストアのガベージコレクションの種類を示します。

ノードストア	データストア	ガベージコレクションのメカニズム
TarMK	TarMK	リビジョンのクリーンアップ（バイナリはセグメントストアと共にインライン）
TarMK	外部ファイルシステム	オペレーションダッシュボードを介したデータストアのガベージコレクションタスク JMX コンソール
MongoDB	MongoDB	オペレーションダッシュボードを介したデータストアのガベージコレクションタスク JMX コンソール
MongoDB	外部ファイルシステム	オペレーションダッシュボードを介したデータストアのガベージコレクションタスク JMX コンソール

操作ダッシュボードによるデータストアのガベージコレクションの実行

操作ダッシュボードから使用できる組み込みの週別メンテナンスウィンドウには、データストアのガベージコレクションを毎週日曜日午前 1 時に起動する組み込みタスクが内蔵されています。

データストアのガベージコレクションを、この時間帯以外に実行する必要がある場合は操作ダッシュボードから手動で起動できます。

データストアのガベージコレクションを実行する前に、その時間にバックアップが実行されていないことを確認してください。

1. ナビゲーション／ツール／操作／メンテナンス​を選択して、操作ダッシュボードを開きます。

2. 「週別メンテナンスウィンドウ」をクリックまたはタップします。

   

3. 「データストアのガベージコレクション」タスクを選択し、実行​アイコンをクリックまたはタップします。

   

4. データストアのガベージコレクションが実行され、そのステータスがダッシュボードに表示されます。

   

JMX コンソールによるデータストアのガベージコレクションの実行

この節では、JMX コンソールを使用してデータストアのガベージコレクションを手動で実行する方法を説明します。外部データストアなしでインストールをセットアップしている場合は、この節で説明する内容は適用されません。その場合は、リポジトリのメンテナンスで説明するリビジョンクリーンアップの実行方法を参照してください。

ガベージコレクションを実行するには：

1. Apache Felix OSGi Management Console で、「メイン」タブをアクティブにし、次のメニューから「JMX」を選択して、

2. 次に、リポジトリマネージャー MBeanを探してクリックします（またはhttps://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagementに移動します）。

3. 「startDataStoreGC(boolean markOnly)」をクリックします。

4. 必要に応じて、markOnlyパラメーターに"true"と入力します。

   オプション	説明
   boolean markOnly	参照のマークのみをおこない、マークスイープ操作でスイープを行わない場合は true に設定します。このモードは、元になる BlobStore が異なる複数のリポジトリで共有されているときに使用されます。それ以外の場合はすべて false に設定してフルガベージコレクションを実行します。

5. 「呼び出し」をクリックします。CRX でガベージコレクションが実行され、完了すると通知されます。

データストアのガベージコレクションの自動化

可能であれば、データストアのガベージコレクションは、（朝など）システムの負荷が低いときに実行してください。

操作ダッシュボードから使用できる組み込みの週別メンテナンスウィンドウには、データストアのガベージコレクションを毎週日曜日午前 1 時に起動する組み込みタスクが内蔵されています。また、その時間にバックアップが実行されていないことを確認する必要もあります。メンテナンスウィンドウの開始時間は、必要に応じてダッシュボードでカスタマイズできます。

オペレーションダッシュボードの週別メンテナンスウィンドウでデータストアのガベージコレクションを実行しない場合は、wgetまたはcurl HTTPクライアントを使用して自動化することもできます。 次の例は、curlを使用してバックアップを自動化する方法を示しています。

次に、コマンドラインからデータストアのガベージコレクションを呼び出すcurlコマンドの例を示します。

curl -u admin:admin -X POST --data markOnly=true  http://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean

curl コマンドはすぐに制御を返します。

データストアの整合性チェック

データストアの整合性チェックは、欠落しているもののまだ参照されているデータストアのバイナリを報告します。整合性チェックを開始するには、次の手順を実行します。

1. JMX コンソールに移動します。JMXコンソールの使用方法について詳しくは、この記事を参照してください。

2. ブロブ GC Mbean を検索し、それをクリックします。

3. checkConsistency()リンクをクリックします。

整合性チェックが完了すると、メッセージに欠落として報告されるバイナリの数が表示されます。0より大きい数値の場合は、error.logを調べて、見つからないバイナリの詳細を調べてください。

欠落しているバイナリがログにどのように表示されるかを次に示します。

11:32:39.673 INFO [main] MarkSweepGarbageCollector.java:600 Consistency check found [1] missing blobs

11:32:39.673 WARN [main] MarkSweepGarbageCollector.java:602 Consistency check failure in the blob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243