現在表示中:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

(Mongo または Segment Tar を備えた)クラスターまたは共有データストアのセットアップでガベージコレクションを実行するときに、特定の blob ID を削除できないことを知らせる警告がログに表示される場合があります。これは、以前のガベージコレクションで削除された blob ID が、その ID が削除されたことを知らない他のクラスターまたは共有ノードによって誤って再度参照されることが原因で発生します。その結果、前回の実行時に既に削除された ID を、ガベージコレクションで再度削除しようとするので、警告がログに記録されます。この動作はパフォーマンスや機能に影響しません。 

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

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

  1. リビジョンクリーンアップ - ノードストアのクリーンアップに一般的に使用されるガベージコレクションメカニズム。
  2. データストアのガベージコレクション - 外部データストア用のガベージコレクションメカニズムで、操作ダッシュボードで使用可能。
  3. JMX コンソール

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

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

ノードストア
データストア ガベージコレクションメカニズム
TarMK TarMK リビジョンクリーンアップ(バイナリはセグメントストアにインライン化されています)
TarMK 外部ファイルシステム

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

JMX コンソール

MongoDB MongoDB

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

JMX コンソール

MongoDB 外部ファイルシステム

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

JMX コンソール

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

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

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

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

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

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

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

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

    chlimage_1

注意:

「データストアのガベージコレクション」タスクは、外部ファイルデータストアが設定されている場合にのみ表示されます。ファイルデータストアのセットアップ方法については、AEM 6 でのノードストアとデータストアの設定を参照してください。

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

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

注意:

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

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

  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 時間以内に削除されたファイルは収集しません。

注意:

データストアのガベージコレクションタスクは、外部ファイルデータストアが設定されている場合にのみ開始されます。外部データストアが設定されていない場合は、このタスクは起動後に Cannot perform operation: no service of type BlobGCMBean found というメッセージを返します。ファイルデータストアのセットアップ方法については、AEM 6 でのノードストアとデータストアの設定を参照してください。

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

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

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

注意:

データストアのガベージコレクションとバックアップを同時に実行しないのには理由があります。それは、古い(および未使用の)データストアファイルもバックアップするためです。これらのデータストアファイルもバックアップしておけば、古いバージョンにロールバックする必要がある場合にバックアップにバイナリが残っています。

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

警告:

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

次に、データストアのガベージコレクションをコマンドラインから起動する 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 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 の規約内容は適用されません。

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