現在表示中:

従来の WCM アセットが削除されると、基になるデータストアレコードへの参照はノード階層から削除される場合がありますが、データストアレコード自体は残ります。この参照されないデータストアレコードが後に、保持する必要のない「ガベージ」となります。多数のガベージアセットが存在するインスタンスでは、それらを削除すると、容量を保持し、バックアップやファイルシステムのメンテナンスパフォーマンスを最適化する上でメリットがあります。

ほとんどの場合、WCM アプリケーションには、収集した情報をそれほど頻繁には削除しない傾向があります。新しい画像が追加され、古いバージョンに取って代わったとしても、バージョン管理システムによって古いバージョンが保持され、必要に応じて元に戻す処理がサポートされます。このように、システムに追加するものと考えられているコンテンツの大多数が、事実上は永久的に保存されます。では、クリーンアップが必要なリポジトリ内の「ガベージ」の元とは、典型的にはどんなものでしょうか。

AEM では、次のような数々の内部アクティビティやハウスキーピングアクティビティのストレージとしてリポジトリを使用します。

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

これらの一時オブジェクトのいずれかが大きくなりすぎてデータストア内にストレージが必要になった場合や、オブジェクトが最終的に使用不可になった場合は、データベースレコード自体が「ガベージ」として残ります。典型的な WCM 作成者/公開アプリケーションでは、このタイプのガベージが発生する最大の原因は、一般的には公開アクティベーションの処理です。公開に対してデータがレプリケートされているとき、データはまず「Durbo」と呼ばれる効率的なデータ形式のコレクションに収集され、リポジトリの /var/replication/data の下に格納されます。データバンドルは多くの場合、データストアの重大なサイズしきい値より大きいので、結果的にデータストアレコードとして格納されます。レプリケーションが完了すると、/var/replication/data 内のノードは削除されますが、データストアレコードは「ガベージ」として残ります。

復元可能なガベージのもう 1 つの原因はパッケージです。パッケージデータは、その他すべてのものと同様に、リポジトリに格納され、4 KB より大きいパッケージはデータストアに格納されます。開発プロジェクトの最中、またはシステムをメンテナンスする過程で、パッケージは何度も構築、再構築される場合があります。構築のたびに新しいデータストアレコードが生成され、前の構築時のレコードは孤立します。

ガベージコレクションの方法

データストアのガベージコレクションは、Tar コンパクションのような日次スケジュールが設定されたアクティビティではありません。システム管理者によって必要に応じて手動で実行されます。一般的に、ガベージコレクションは定期的に実行することをお勧めしていますが、ガベージコレクションの計画には次の要素を考慮する必要があります。

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

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

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

第 2 段階では、ガベージコレクターはデータストアの物理的ディレクトリ構造を、「検索」とほぼ同じ方法でトラバースします。ファイルの「最終変更」(MTIME)属性を調べ、以下の決定を下します。

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

このアプローチは、非公開のデータストアを持つ単一ノードに適しています。ただし、データストアは共有可能であり、共有した場合、他のリポジトリからのデータレコードに対してアクティブである可能性のあるライブ参照がチェックされず、参照されているアクティブなファイルが誤って削除される場合があります。システム管理者は、ガベージコレクションを計画する前に、データストアの共有可能な性質を理解し、データストアが共有されないことが分かっている場合にのみ、単純な組み込みのガベージコレクション処理を使用する必要があります。

ガベージコレクションの実行

ガベージコレクションの実行は、AEM が実行されているデータストアの設定により、2 つの方法が用意されています。

  1. Tar コンパクションを介して。運営ダッシュボードで使用可能なガベージコレクションのメカニズムです。
  2. JMX コンソールを介して。

Tar コンパクションは、TarMK がノードストアとデータストアの両方で使用されているときに必要で、JMX コンソールを介する明示的なガベージコレクションは、バイナリデータがファイルシステムデータストアなどの外部データストアに保存されているときに使用されます。

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

ノードストア
データストア ガベージコレクションのメカニズム
TarMK TarMK Tar コンパクション
TarMK 外部ファイルシステム JMX コンソール
MongoDB MongoDB 不要
MongoDB 外部ファイルシステム JMX コンソール

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

ここでは、JMX コンソールを使用したデータストアのガベージコレクションについて説明します。Tar コンパクションの実行方法について詳しくは、リポジトリのメンテナンスのドキュメントを参照してください。

注意:

TarMK を外部データストアで実行している場合、ガベージコレクションを有効にするには、まず Tar コンパクションを実行する必要があります。

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

  1. Apache Felix OSGi Management Console で、「メイン」タブをアクティブにし、次のメニューから「JMX」を選択して、リポジトリマネージャー MBean を選択(または http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D14%2Cname%3D%22repository+manager%22%2Ctype%3D%22RepositoryManagement%22 に移動)します。

  2. 次に、リポジトリマネージャー MBean を検索してクリック(または http://host:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D14%2Cname%3D%22repository+manager%22%2Ctype%3D%22RepositoryManagement%22 に移動)します。

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

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

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

注意:

データストアのガベージコレクションでは、過去 24 時間以内に削除されたファイルは収集しません。

ガベージコレクションの自動化

可能な場合は、ガベージコレクションはシステムの負荷が低いとき(朝など)に実行してください。デフォルトでは、Tar コンパクションが午前 2 時~午前 5時に実行され、この処理でもシステムの速度が低下します。そのため、ガベージコレクションを実行するのに適した時間は午前 5 時となります。ただし、この時間にバックアップが実行されていないことを確認する必要があります。

注意:

同時に実行しない理由は、古い(および未使用の)データストアファイルもバックアップされるようにするためです。古いバージョンにロールバックする必要がある場合に備えて、バイナリがバックアップに残してあります。

ガベージコレクションは、wget または curl の HTTP クライアントを使用して自動化できます。curl を使用してバックアップを自動化する例を以下に示します。

警告:

以下の例の curl コマンドでは、様々なパラメーターをインスタンス用に設定する必要があります。例えば、ホスト名(localhost)、ポート(4502)、管理者パスワード(xyz)および実際のガベージコレクションの様々なパラメーターなどです。

次の例のようにガベージコレクションを実行します。

curl -u admin:xyz -X POST --data markOnly=false http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D14%2Cname%3D%22repository+manager%22%2Ctype%3D%22RepositoryManagement%22/op/startDataStoreGC/boolean

サーバーでガベージコレクションが完了すると、curl コマンドが返ります。

上記の例では、markOnlyパラメーターは false に設定されています。有効にするには、--data markOnly=true を使用します。

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

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

  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 the blob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー