従来の WCM アセットを削除すると、データストアレコードの参照がノード階層から削除されますが、データストアレコード自体は削除されずに残ります。その結果、どこからも参照されることのないこのデータストアレコードは、不要な「ガベージ」として残ることになります。例えば、インスタンスにいくつかのガベージアセットが存在する場合、そのガベージアセットを削除すれば、領域を保護して、バックアップやファイルシステムのメンテナンスのパフォーマンスを最適化できます。
ほとんどの場合、WCM アプリケーションは、情報は収集しても、あまり頻繁に情報を削除しません。旧バージョンより優先する新しい画像が追加されたとしても、バージョン管理システムは、いつでも旧バージョンに戻せるように旧バージョンを残します。その結果、システムに追加されるコンテンツは、そのほとんどが永続的に保存されることになります。それでは、いったい何が原因でリポジトリ内に不要な「ガベージ」が生み出されるのでしょうか。
AEM では、以下に示す様々な内部アクティビティやハウスキーピングアクティビティのオブジェクトをリポジトリに保管します。
これらの一時オブジェクトがデータストア内の領域をある程度消費するほど大きく、しかもそのオブジェクトが最終的に使用されなかった場合は、そのデータストアレコード自体が「ガベージ」として残ります。標準的な WCM オーサー/パブリッシュアプリケーションの場合、このようなガベージが生まれる最大の原因は、一般的に、パブリッシュアクティベーションのプロセスにあります。データはパブリッシュにレプリケーションされる際、まず「Durbo」という名前の効率的なデータ形式でコレクションに収集されて、リポジトリ内の /var/replication/data
に保存されます。データバンドルは通常、データストアの上限サイズを超えるので、最終的にデータストアレコードとして保存されます。レプリケーションが完了すると、/var/replication/data
内のノードは削除されますが、データストアレコードは「ガベージ」として残ります。
回収可能なガベージが生まれるもう 1 つの原因はパッケージです。他のデータもそうですが、パッケージデータもリポジトリ内に保存され、4 KB を超えるパッケージはデータストア内に保存されます。開発プロジェクトの工程やその後のシステムのメンテナンスでは、パッケージのビルドとリビルドが何度もおこなわれ、ビルドがおこなわれるたびに新しいデータストアレコードができて、以前のビルドのレコードは孤立します。
リポジトリが外部データストアに設定されている場合、週別メンテナンスウィンドウの一部として、データストアのガベージコレクションは自動的に実行されます。また、システム管理者は必要に応じて、データストアのガベージコレクションを手動で実行することもできます。一般的に、データストアのガベージコレクションは定期的に実行することが推奨されますが、データストアのガベージコレクションを計画するときは、次の事項を考慮する必要があります。
データストアのガベージコレクターは最初に、プロセスを開始する際に現在のタイムスタンプを記録します。その後、マルチパスマーク/消去パターンアルゴリズムを使用してガベージコレクションが実行されます。
第 1 段階では、データストアのガベージコレクターは、すべてのリポジトリコンテンツを包括的に調べます。データストアレコードを参照する各コンテンツオブジェクトについて、データストアのガベージコレクターは、ファイルシステムからファイルを見つけてメタデータの更新を実行し、「最終変更日」または MTIME 属性を変更します。この時点で、この段階までにアクセスされたファイルは、当初のベースラインタイムスタンプより新しいものになります。
第 2 段階では、データストアのガベージコレクターは、「検索」とほとんど同じ方法で、データストアの物理的なディレクトリ構造を調べます。データストアのガベージコレクターは、ファイルの「最終変更日」または MTIME 属性を調べて、次の判断をおこないます。
この方法は、プライベートなデータストアを持つ単一のノードに適しています。ただし、データストアは共有されている場合があります。その場合、他のリポジトリからデータストアレコードへのアクティブなライブ参照はチェックされず、そのアクティブな参照ファイルが誤って削除される可能性があります。システム管理者はガベージコレクションを計画する前に、データストアが共有されていないかどうかを確認し、データストアが共有されていないことが明確な場合にのみ、シンプルな組み込みデータストアのガベージコレクションプロセスを使用するようにしてください。
(Mongo または Segment Tar を備えた)クラスターまたは共有データストアのセットアップでガベージコレクションを実行するときに、特定の blob ID を削除できないことを知らせる警告がログに表示される場合があります。これは、以前のガベージコレクションで削除された Blob ID が、その ID が削除されたことを知らない他のクラスターまたは共有ノードによって誤って再度参照されることが原因で発生します。その結果、前回の実行時に既に削除された ID を、ガベージコレクションで再度削除しようとするので、警告がログに記録されます。この動作はパフォーマンスや機能に影響しません。
データストアのガベージコレクションは、AEM が実行されているデータストアのセットアップに応じて、3 つの方法で実行できます。
リビジョンクリーンアップ経由 - ノードストアのクリーンアップに一般的に使用されるガベージコレクションメカニズム。
データストアのガベージコレクション - 外部データストア用のガベージコレクションメカニズムで、操作ダッシュボードで使用可能。
TarMK がノードストアとデータストアの両方として使用されている場合は、その両方のガベージコレクションにリビジョンクリーンアップを使用できます。一方、ファイルシステムデータストアなど外部データストアが設定されている場合は、リビジョンクリーンアップとは別に、データストアのガベージコレクションを明示的に起動する必要があります。データストアのガベージコレクションは、操作ダッシュボードと JMX コンソールのどちらからでも起動できます。
次の表に、AEM 6 でサポートされているすべてのデータストアのデプロイメントで使用する必要がある、データストアのガベージコレクションの種類を示します。
ノードストア |
データストア | ガベージコレクションのメカニズム |
TarMK | TarMK | リビジョンクリーンアップ(バイナリはセグメントストアとインライン化されています) |
TarMK | 外部ファイルシステム | 操作ダッシュボードを使用したデータストアのガベージコレクションタスク JMX コンソール |
MongoDB | MongoDB | 操作ダッシュボードを使用したデータストアのガベージコレクションタスク JMX コンソール |
MongoDB | 外部ファイルシステム | 操作ダッシュボードを使用したデータストアのガベージコレクションタスク JMX コンソール |
操作ダッシュボードから使用できる組み込みの週別メンテナンスウィンドウには、データストアのガベージコレクションを毎週日曜日午前 1 時に起動するタスクが組み込まれています。
データストアのガベージコレクションを、この時間帯以外に実行する必要がある場合は操作ダッシュボードから手動で起動できます。
データストアのガベージコレクションを実行する前に、その時間にバックアップが実行されていないことを確認してください。
ナビゲーション/ツール/操作/メンテナンスを選択して、操作ダッシュボードを開きます。
「週別メンテナンスウィンドウ」をクリックまたはタップします。
「データストアのガベージコレクション」タスクを選択し、実行アイコンをクリックまたはタップします。
データストアのガベージコレクションが実行され、そのステータスがダッシュボードに表示されます。
「データストアのガベージコレクション」タスクは、外部ファイルデータストアが設定されている場合にのみ表示されます。ファイルデータストアのセットアップ方法については、AEM 6 でのノードストアとデータストアの設定を参照してください。
この節では、JMX コンソールを使用してデータストアのガベージコレクションを手動で実行する方法を説明します。外部データストアなしでインストールをセットアップしている場合は、この節で説明する内容は適用されません。その場合は、リポジトリのメンテナンスで説明するリビジョンクリーンアップの実行方法を参照してください。
TarMK を外部データストアで実行している場合、ガベージコレクションを有効にするには、最初にリビジョンクリーンアップを実行する必要があります。
ガベージコレクションを実行するには:
Apache Felix OSGi Management Console で、「メイン」タブをアクティブにし、次のメニューから「JMX」を選択して、
次に、「リポジトリマネージャー MBean」を検索して、クリックします(またはhttps://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement
に移動します)。
「startDataStoreGC(boolean markOnly)」をクリックします。
必要に応じて、markOnly
パラメーターに「true
」と入力します。
オプション | 説明 |
---|---|
boolean markOnly | 参照のマークのみをおこない、マークスイープ操作でスイープを行わない場合は true に設定します。このモードは、元になる BlobStore が異なる複数のリポジトリで共有されているときに使用されます。それ以外の場合はすべて false に設定してフルガベージコレクションを実行します。 |
「呼び出し」をクリックします。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 コマンドはすぐに制御を返します。
データストアの整合性チェックは、欠落しているもののまだ参照されているデータストアのバイナリを報告します。整合性チェックを開始するには、次の手順を実行します。
JMX コンソールに移動します。JMX コンソールの使い方について詳しくは、この記事を参照してください。
ブロブ GC Mbean を検索し、それをクリックします。
「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