ドキュメントAEM 6.4管理ガイド

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

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

作成対象：

  • Admin
CAUTION
AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

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

ほとんどの場合、WCM アプリケーションは情報を収集しますが、情報を削除する頻度はほぼ同じではありません。 新しい画像が追加されても、古いバージョンに代わる場合でも、バージョン管理システムは古い画像を保持し、必要に応じて元に戻すことができます。 したがって、システムに追加されると考えられるコンテンツの大部分は、事実上、永久に保存されます。 では、クリーンアップしたいリポジトリの「ごみ箱」の一般的なソースは何ですか？

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

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

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

回復可能なガベージのもう 1 つのソースはパッケージです。 パッケージデータは、他のすべてと同様に、リポジトリに格納されるので、4KB を超えるパッケージの場合はデータストアに格納されます。 開発プロジェクトの過程、またはシステムを維持しながら時間の経過と共に、パッケージを何度もビルドおよび再構築し、各ビルドが新しいデータストアレコードを生成し、以前のビルドのレコードを孤立させることができます。

データストアのガベージコレクションはどのように機能しますか？ how-does-data-store-garbage-collection-work

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

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

データストアのガベージコレクターは、まず、プロセスが開始したときに現在のタイムスタンプをメモします。 次に、マルチパスマーク/スイープパターンアルゴリズムを使用してコレクションを実行します。

第 1 段階では、データストアのガベージコレクターが、すべてのリポジトリコンテンツを包括的にトラバーサルします。 データストアレコードへの参照を持つ各コンテンツオブジェクトに対して、ファイルシステム内のファイルを配置し、メタデータ更新を実行します（「最終変更日」または MTIME 属性を変更）。 この時点で、このフェーズでアクセスされるファイルは、初期ベースラインタイムスタンプよりも新しくなります。

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

  • MTIME が初期ベースラインタイムスタンプより新しい場合は、最初の段階でファイルが見つかったか、収集プロセスが進行中にリポジトリに追加されたまったく新しいファイルです。 どちらの場合も、レコードはアクティブと見なされ、ファイルは削除されません。
  • MTIME が初期ベースラインタイムスタンプより前の場合、そのファイルはアクティブに参照されるファイルではなく、リムーバブルガベージと見なされます。

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

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

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

データストアのガベージコレクションを実行する方法は 3 つあります。実行するデータストアの設定に応じて、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-121

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

    chlimage_1-122

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

    chlimage_1-123

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

JMX コンソールを使用したデータストアのガベージコレクションの実行 running-data-store-garbage-collection-via-the-jmx-console

この節では、JMX コンソールを使用してデータストアのガベージコレクションを手動で実行する方法について説明します。 外部データストアを使用せずにインストールを設定した場合、この設定はインストールには適用されません。 代わりに、次のリビジョンクリーンアップの実行方法に関する手順を参照してください： リポジトリの保守.

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

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

  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」と入力します。

    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  http://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 コンソールの使い方について詳しくは、この記事を参照してください。

  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
recommendation-more-help
5ce3024a-cbea-458b-8b2f-f9b8dda516e8