ドキュメントAEM 6.5ユーザーガイド

データストアのガベージコレクション data-store-garbage-collection

Last update: Tue Aug 20 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
  • トピック：

作成対象：

  • 管理者

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

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

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

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

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

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

データストアのガベージコレクションの機能 how-does-data-store-garbage-collection-work

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

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

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

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

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

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

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

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

データストアのガベージコレクションの実行 running-data-store-garbage-collection

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

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

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

  3. JMX コンソールを介して。

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

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

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

操作ダッシュボードを使用したデータストアのガベージコレクションタスク

JMX コンソール

MongoDB
MongoDB

操作ダッシュボードを使用したデータストアのガベージコレクションタスク

JMX コンソール

MongoDB
外部ファイルシステム

操作ダッシュボードを使用したデータストアのガベージコレクションタスク

JMX コンソール

操作ダッシュボードによるデータストアのガベージコレクションの実行 running-data-store-garbage-collection-via-the-operations-dashboard

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

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

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

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

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

    chlimage_1-64

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

    chlimage_1-65

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

    chlimage_1-66

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

JMX コンソールによるデータストアのガベージコレクションの実行 running-data-store-garbage-collection-via-the-jmx-console

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

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

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

  1. Apache Felix OSGi 管理コンソールで、「メイン」タブをアクティブにし、次のメニューから「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」と入力します。

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

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

NOTE
データストアのガベージコレクションでは、過去 24 時間以内に削除されたファイルは収集しません。
NOTE
データストアのガベージコレクションタスクは、外部ファイルデータストアが設定されている場合にのみ開始されます。外部ファイルデータストアが設定されていない場合は、このタスクは呼び出し後に Cannot perform operation: no service of type BlobGCMBean found というメッセージを返します。ファイルデータストアのセットアップ方法については、AEM 6 でのノードストアとデータストアの設定を参照してください。

データストアのガベージコレクションの自動化 automating-data-store-garbage-collection

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

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

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

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

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

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

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

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

データストアの整合性チェック checking-data-store-consistency

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

  1. JMX コンソールに移動します。JMX コンソールの使用方法について詳しくは、JMX コンソールを使用したサーバーリソースの監視を参照してください。
  2. BlobGarbageCollection 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 intheblob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243
recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2