Show Menu
トピック×

リビジョンクリーンアップ

概要

リポジトリが更新されるたびに、新しいコンテンツのリビジョンが作成されます。その結果、更新のたびにリポジトリのサイズが大きくなります。 リポジトリのサイズが無制限に増大しないように、古いリビジョンをクリーンアップして、ディスクリソースを解放する必要があります。このメンテナンス機能は、リビジョンクリーンアップと呼ばれます。AEM 6.0 以降では、この機能をオフラインルーチンとして使用できます。
AEM 6.3 では、この機能のオンラインバージョンである「オンラインでのリビジョンクリーンアップ」が導入されました。AEM インスタンスをシャットダウンする必要があったオフラインのリビジョンクリーンアップとは異なり、オンラインでのリビジョンクリーンアップは AEM インスタンスがオンラインの状態で実行できます。オンラインでのリビジョンクリーンアップはデフォルトで有効になります。リビジョンクリーンアップを実行する際はこの方法を使用することが推奨されます。
注意 :概要 revision-cleanup-technical-video-use.html とオンラインリビジョンのクリーンアップの使い方については、ビデオを参照してください。
リビジョンクリーンアップのプロセスは、 見積もり コンパクション ​および​ クリーンアップ ​の 3 つのフェーズで構成されます。見積もりでは、収集される可能性があるガベージの量に基づいて、次のフェーズ(コンパクション)を実行するかどうかが判別されます。コンパクションフェーズでは、セグメントおよび tar ファイルが未使用のコンテンツを除いて再作成されます。次のクリーンアップフェーズでは、含まれているガベージを含め、古いセグメントが削除されます。通常、オフラインモードのほうが多くの領域を再利用できます。これは、オンラインモードでは AEM の作業セットを保持する必要があり、収集されないセグメントがあるためです。
リビジョンクリーンアップについて詳しくは、以下のリンクを参照してください。
Additionally, you can also read the official Oak documentation.

When to use Online Revision Cleanup as opposed to Offline Revision Cleanup?

推奨されているリビジョンクリーンアップの実行方法は、オンラインでのリビジョンクリーンアップです。 オフラインリビジョンのクリーンアップは、例えば、新しいストレージ形式に移行する前、またはアドビカスタマーケアから要求を受けた場合など、例外的に使用する必要があります。

オンラインでのリビジョンクリーンアップの実行方法

オンラインでのリビジョンクリーンアップは、デフォルトで、AEM のオーサーインスタンスとパブリッシュインスタンスの両方で、自動的に 1 日に 1 回実行されるように設定されています。必要な作業は、ユーザーアクティビティが最も少ない時間帯にメンテナンスウィンドウを定義することのみです。オンラインでのリビジョンクリーンアップのタスクを設定するには、以下のようにします。
  1. In the main AEM window, go to Tools - Operations - Dashboard - Maintenance or point your browser to: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
  2. Hover over Daily Maintenance Window and click the Settings icon.
  3. Enter the desired values (recurrence, start time, end time) and click Save .
または、リビジョンクリーンアップのタスクを手動で実行する場合は、次の手順を実行します。
  1. Go to Tools - Operations - Dashboard - Maintenance or browse directly to https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
  2. Click the Daily Maintenance Window .
  3. Hover over the Revision Cleanup icon.
  4. 実行 」をクリックします。

オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合

リビジョンクリーンアップのプロセスでは、古いリビジョンを世代ごとに再利用します。つまり、リビジョンクリーンアップを実行するたびに新しい世代を作成し、ディスク上に保持します。ただし、2種類のリビジョンクリーンアップには違いがあります。オフラインリビジョンのクリーンアップでは1世代が維持され、オンラインリビジョンのクリーンアップでは2世代が維持されます。 So, when you run online revision cleanup after offline revision cleanup the following happens:
  1. 最初のオンラインリビジョンのクリーンアップを実行した後、リポジトリのサイズが2倍になります。 これは、ディスク上に 2 つの世代が保持されるからです。
  2. 後続の実行中は、新しい世代が作成される間、リポジトリが一時的に拡張され、最初の実行後に元のサイズに再び安定します。これは、オンラインリビジョンのクリーンアッププロセスが前の世代を再利用するためです。
また、コミットの種類と回数に応じて、各世代のサイズが以前の世代とは変わってくる場合があります。したがって、最終的なサイズは実行ごとに変動する可能性があります。
この点を考慮し、最初に予測したリポジトリサイズよりも少なくとも 2 倍または 3 倍大きなディスクサイズにすることをお勧めします。

フルコンパクションモードとテールコンパクションモード

AEM 6.4 では、オンラインでのリビジョンクリーンアッププロセスの​ コンパクション ​フェーズ用に 2 つの新しいモード ​が導入されています。
  • フルコンパクション ​モードでは、リポジトリ全体のすべてのセグメントと tar ファイルが書き換えられます。したがって、後続のクリーンアップフェーズでは、リポジトリ全体の最大量のガベージを削除できます。フルコンパクションはリポジトリ全体に影響を与えるので、完了するにはかなりの量のシステムリソースと時間が必要です。フルコンパクションは、AEM 6.3 のコンパクションフェーズに対応しています。
  • テールコンパクション ​モードでは、リポジトリの最新のセグメントと tar ファイルのみが書き換えられます。最新のセグメントと tar ファイルとは、フルコンパクションまたはテールコンパクションの前回の実行以降に追加されたセグメントと tar ファイルのことです。したがって、後続のクリーンアップフェーズでは、リポジトリの新しい部分に含まれるガベージのみを削除できます。尾の圧縮はリポジトリの一部にしか影響しないので、完全圧縮よりも完了するのに必要なシステムリソースと時間が大幅に少なくなります。
この 2 つのコンパクションモードでは、効果とリソース消費がトレードオフの関係にあります。テールコンパクションは効果は低くなりますが、システムの通常運用に与える影響も少なくなります。これに対し、フルコンパクションは効果は高くなりますが、システムの通常運用に大きな影響を与えます。
また、AEM 6.4 では、コンパクション時のより効率的なコンテンツの重複除外メカニズムが導入されました。これにより、リポジトリのディスク上のフットプリントがさらに削減されます。
次の 2 つの図は、AEM 6.3 と比較した AEM 6.4 の平均実行時間とディスク上の平均フットプリントの減少を示す社内ラボでのテスト結果を示しています。

フルコンパクションとテールコンパクションの設定方法

デフォルト設定では、テールコンパクションを平日に、フルコンパクションを日曜日に実行します。The default configuration can be changed by using the new configuration value full.gc.days of the RevisionCleanupTask maintenance task .
When you configure the full.gc.days value be aware that full compaction will run during the day(s) defined in the value and tail compaction will run during the days that are not defined in the value. 例えば、フルコンパクションを日曜日に実行するように設定すると、テールコンパクションは月曜日から土曜日に実行されます。例えば、フルコンパクションを毎日実行するように設定すると、テールコンパクションはまったく実行されません。
また、次のことを考慮に入れてください。
  • テールコンパクション ​は、効果が低く、システムの通常運用に対する影響が少なくなります。そのため、テールコンパクションは営業日に実行することを意図しています。
  • フルコンパクション ​は、効果は高くなりますが、システムの通常運用に大きな影響を与えます。そのため、原則的には休業日に実行します。
  • テールコンパクションとフルコンパクションは両方とも、オフピークの時間帯に実行するように計画することをお勧めします。

トラブルシューティング

新しいコンパクションモードを使用する場合、次の点に注意してください。
  • 入出力(I/O)アクティビティ(例:I/O 操作、I/O を待機する CPU、コミットキューサイズ)を監視できます。これは、システムが I/O バウンドになりつつあり、アップサイジングが必要かどうかを特定するのに役立ちます。
  • The RevisionCleanupTaskHealthCheck indicates the overall health status of the Online Revision Cleanup. AEM 6.3 と同じように機能し、フルコンパクションとテールコンパクションを区別しません。
  • ログメッセージは、コンパクションモードについての関連情報を伝えます。例えば、オンラインでのリビジョンクリーンアップを開始する際に、対応するログメッセージはコンパクションモードを示します。また、まれに、テールコンパクションを実行するようスケジュールされていたがシステムがフルコンパクションに戻った場合は、ログメッセージにこの変更が示されます。次のログサンプルは、コンパクションモード、およびテールコンパクションからフルコンパクションへの変更を示しています。
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

既知の制限事項

場合によっては、テールとフルのコンパクションモードの変更によりクリーンアッププロセスが遅延します。正確には、フルコンパクションの後にリポジトリが大きくなります(倍のサイズになります)。リポジトリがフルコンパクション前のサイズ以下になると、余分のスペースが後続のテールコンパクションで再利用されます。メンテナンスタスクの並列実行も回避する必要があります。
最初に予測したリポジトリサイズよりも少なくとも 2 倍または 3 倍大きなディスクサイズにすることをお勧めします。

オンラインでのリビジョンクリーンアップに関するよくある質問

AEM 6.4 のアップグレードに関する考慮事項

質問 回答
AEM 6.4 にアップグレードするときの注意点を教えてください。
TarMK の永続性形式が AEM 6.4 で変更されます。これらの変更には、事前の移行手順は必要ありません。既存のリポジトリは、周期的な移行を実行します。これはユーザーに対して透過的です。AEM 6.4(または関連ツール)がリポジトリに初めてアクセスすると、移行プロセスが開始されます。
AEM 6.4永続化形式への移行が開始されると、リポジトリを以前のAEM 6.3永続化形式に戻すことはできません。

Oak Segment Tar への移行

質問 回答
リポジトリを移行する必要があるのはなぜですか。
AEM 6.3では、特にオンラインリビジョンクリーンアップのパフォーマンスと有効性を改善するために、ストレージ形式の変更が必要でした。 この変更には後方互換性がないので、古い Oak セグメント(AEM 6.2 以前)で作成されたリポジトリを移行する必要があります。
ストレージ形式の変更には、他にも次のような利点があります。
以前の Tar 形式もサポートされますか。 AEM 6.3 では、新しい OAK Segment Tar のみがサポートされます。
コンテンツの移行は常に必須ですか。 はい。新しいインスタンスを使用する場合を除き、常にコンテンツを移行する必要があります。
6.3 にアップグレードしてから、(例えば、別のメンテナンスウィンドウを使用して)後で移行を実行できますか。 できません。前述のとおり、コンテンツの移行は必須です。
移行時のダウンタイムは回避できますか。 いいえ. これは一度におこなう作業であり、実行中のインスタンスでは実行できません。
誤って不適切なリポジトリ形式に対して移行を実行した場合はどうなりますか。 If you try to run the oak-segment module against an oak-segment-tar repository (or vice versa), startup will fail with an IllegalStateException with the message "Invalid segment format". データが破損することはありません。
検索インデックスの再作成は必要ですか。 いいえ. oak-segmentからoak-segment-tarに移行すると、コンテナの形式に変更が加えられます。 含まれているデータに影響はなく、データは変更されません。
移行中および移行後に必要と予想されるディスク領域を計算する最適な方法を教えてください。 移行とは、セグメントストアを新しい形式で作成し直すことと同義です。これを利用して、移行中に必要な追加のディスク領域を推定できます。移行後は、領域を再利用するために古いセグメントストアを削除できます。
移行時間の最適な見積もり方法を教えてください。 Migration performance can be greatly improved if offline revision cleanup is executed prior to the migration. アップグレードプロセスの前提条件として、オフラインでのリビジョンクリーンアップを実行することをすべての顧客にお勧めします。通常、移行の期間は、オフラインリビジョンのクリーンアップタスクの期間と同じにする必要があります(移行前にオフラインリビジョンのクリーンアップタスクが実行されている場合)。

オンラインでのリビジョンクリーンアップの実行

質問 回答
オンラインでのリビジョンクリーンアップは、どのくらいの頻度で実行する必要がありますか。 1 日に 1 回です。これが操作ダッシュボードでのデフォルト設定です。
オンラインでのリビジョンクリーンアップのメンテナンスタスクを開始する時間を設定する方法を教えてください。 See the How to run Online Revision Cleanup section.
オンラインでのリビジョンクリーンアップには、超過するべきではない実行頻度の上限がありますか。 オンラインでのリビジョンクリーンアップは、デフォルト設定のとおり、1 日に 1 回実行することをお勧めします。
オンラインでのリビジョンクリーンアップの実行頻度を決定する主な指標は何ですか。 オンラインでのリビジョンクリーンアップはメンテナンスタスクとして設定され、毎日自動的に実行されるので、実行頻度を決定する必要はありません。
オンラインでのリビジョンクリーンアップを初めて実行したときに、領域が再利用されないのはなぜですか。 オンラインでのリビジョンクリーンアップでは、古いリビジョンを世代ごとに再利用します。リビジョンクリーンアップが実行されるたびに、新しい世代が生成されます。2 世代以上前のコンテンツのみが再利用されるので、初回実行時には再利用するコンテンツがありません。
オフラインでのリビジョンクリーンアップの実行後に初めてオンラインでのリビジョンクリーンアップを実行したときに、領域が再利用されないのはなぜですか。
オフラインでのリビジョンクリーンアップでは最新の世代だけを残して他をすべて再利用しますが、オンラインでのリビジョンクリーンアップでは最新の 2 つの世代を残します。新しいリポジトリの場合、オフラインでのリビジョンクリーンアップの実行後に初めてオンラインでのリビジョンクリーンアップが実行されるときには、再利用できる古い世代が存在しないので、領域は再利用されません。
この章 の「オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合」の節も参照してください。
オンラインでのリビジョンクリーンアップは、通常、オーサーとパブリッシュでは異なる時間帯に実行しますか。 いつ実行すべきかは、営業時間と顧客のオンラインプレゼンスのトラフィックパターンによって異なります。最適なクリーンアップ効果を実現するには、メインの実稼働時間の外側にメンテナンスウィンドウを設定する必要があります。 複数のAEM発行インスタンス(TarMKファーム)の場合は、オンラインリビジョンクリーンアップのメンテナンスウィンドウを調整する必要があります。
オンラインでのリビジョンクリーンアップを実行するための前提条件はありますか。
オンラインリビジョンのクリーンアップは、AEM 6.3以降のリリースでのみ使用できます。 また、古いバージョンの AEM を使用している場合は、新しい Oak Segment Tar に移行する必要があります。
オンラインでのリビジョンクリーンアップの時間に作用する要因は何ですか。 次の要因があります。
  • リポジトリのサイズ
  • システムの負荷(要求数/分、特に書き込み操作)
  • アクティビティのパターン(読み取りと書き込み)
  • ハードウェアの仕様(CPU の性能、メモリ、IOPS)
オンラインでのリビジョンクリーンアップの実行中も作成者は作業できますか。 できます。オンラインでのリビジョンクリーンアップは、同時書き込みに対応しています。ただし、同時書き込みトランザクションがおこなわれていないほうが、オンラインでのリビジョンクリーンアップの動作は高速かつ効率的になります。オンラインでのリビジョンクリーンアップのメンテナンスタスクは、大量のトラフィックがない、比較的処理が少ない時間帯にスケジュールすることをお勧めします。
オンラインでのリビジョンクリーンアップを実行するときのディスク領域とヒープメモリの最小要件を教えてください。
オンラインでのリビジョンクリーンアップ中、ディスク領域は継続的に監視されます。使用可能なディスク領域が臨界値を下回ると、プロセスがキャンセルされます。臨界値はリポジトリの現在のディスクフットプリントの 25 %で、設定はできません。
最初に予測したリポジトリサイズよりも少なくとも 2 倍または 3 倍大きなディスクサイズにすることをお勧めします。
クリーンアッププロセス中、空きヒープ領域が継続的に監視されます。空きヒープ領域が臨界値を下回ると、プロセスがキャンセルされます。重要な値はorg.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLDを使用して設定します。 デフォルト値は 15%です。
推奨されるコンパクションヒープの最小サイズは、AEM のメモリサイズの推奨値と関係があります。原則として、 AEM インスタンスのサイズが使用例およびそこで予想されるペイロードに対処するために十分なサイズであれば、クリーンアッププロセスで十分なメモリが確保されます。
オンラインでのリビジョンクリーンアップの実行中、パフォーマンスにはどのような影響があると予想されますか。 オンラインでのリビジョンクリーンアップでは、通常のシステム操作と並行して、リポジトリからの読み取りおよびリポジトリへの書き込みをバックグラウンドプロセスとして実行します。状況によっては、リポジトリに対する短時間の排他的アクセスが必要になり、他のスレッドがリポジトリに書き込めなくなる場合があります。
オンラインでのリビジョンクリーンアップの所要時間はどのくらいですか。 アドビ内部で実行した最新のパフォーマンステストによると、所要時間は 2 時間以下です。
オンラインでのリビジョンクリーンアップにそれよりも長い時間がかかる場合はどうすればよいですか。
  • クリーンアップが毎日実行されていることを確認してください。
  • Operations Dashboardでメンテナンスウィンドウを設定して、最小限のリポジトリアクティビティ中に必ず実行するようにします。
  • システムリソース(CPU、メモリ、I/O)を拡張してください。
設定したメンテナンスウィンドウ中にオンラインでのリビジョンクリーンアップが終わらない場合は、何が起きていますか。 他のメンテナンスタスクがリビジョンクリーンアップの実行を遅延させていないかを確認してください。これは、同じメンテナンスウィンドウ内で、オンラインでのリビジョンクリーンアップ以外のメンテナンスタスクも実行されている場合に発生することがあります。メンテナンスタスクは順番に実行されますが、順序は設定できないことに注意してください。
リビジョンのガベージコレクションがスキップされるのはなぜですか。
リビジョンクリーンアップでは、まず見積もりフェーズによって、クリーンアップが必要なガベージが累積しているかどうかが判断されます。見積もりでは、最後のコンパクション後のリポジトリサイズと現在のサイズを比較します。このサイズが設定されている差分を超えている場合、クリーンアップが実行されます。サイズの差分は1 GBに設定されます。 つまり、リポジトリのサイズが前回のクリーンアップ実行以降に1 GB増えなかった場合、新しいリビジョンのクリーンアップの繰り返しはスキップされます。
見積もりフェーズに関連するログエントリは以下のとおりです。
  • Revision GC will run: Size delta is N% or N/N (N/N bytes), so running compaction
  • Revision GC will not run: Size delta is N% or N/N (N/N bytes), so skipping compaction for now
パフォーマンスへの影響が大きすぎる場合に、自動コンパクションを安全に中止できますか。 はい。AEM 6.3 以降では、操作ダッシュボード内のメンテナンスタスクウィンドウまたは JMX を使用して、安全に停止できます。
スケジュールされたクリーンアップタスクの実行中に AEM インスタンスがシャットダウンされた場合、プロセスは安全に中止されますか。またはコンパクションが終了するまでシャットダウンがブロックされますか。 リビジョンクリーンアップが中断され、リポジトリは安全にシャットダウンされます。
オンラインでのリビジョンクリーンアップ中にシステムがクラッシュした場合はどうなりますか。 そのような場合も、データが破損するリスクはありません。ガベージの残りは後続の実行でクリーンアップされます。
オンラインでのリビジョンクリーンアップを実行しないと、どのような影響がありますか。 時間の経過に伴いパフォーマンスが低下します。
どのリビジョンが収集されますか。 デフォルトでは、オンラインでのリビジョンクリーンアップで収集されるのは 24 時間以上前のリビジョンのみです。
同時書き込みからリポジトリへの過度の干渉が発生した場合、どうなりますか。
同時書き込みが可能なシステムでは、コンパクションサイクルの終了時に変更をコミットできるように、オンラインでのリビジョンクリーンアップで排他書き込みアクセスが必要になる場合があります。The system will go into forceCompact mode , as explained in more detail in the oak documentation . 強制コンパクション中は、同時書き込みによる干渉を受けることなく最終的に変更をコミットするために、排他書き込みロックが取得されます。応答時間に対する影響を制限するために、タイムアウト値を定義できます。デフォルトでは、この値は 1 分に設定されています。これは、1 分以内に強制コンパクションが完了しない場合、同時コミットが優先されてコンパクションプロセスが中止されることを意味します。
力のコンパクト化の時間は、次の要因によって異なります。
  • ハードウェア(具体的には IOPS):IOPS が増えると実行時間が短縮されます。
  • セグメントストアサイズ:実行時間はセグメントストアのサイズに伴って増大します。
スタンバイインスタンスでは、オンラインでのリビジョンクリーンアップはどのように実行されますか。
コールドスタンバイセットアップでは、オンラインでのリビジョンクリーンアップの実行を設定する必要があるのは、プライマリインスタンスのみです。スタンバイ・インスタンスでは、オンライン・リビジョン・クリーンアップを特別にスケジュールする必要はありません。
スタンバイインスタンスでの対応する操作は、自動クリーンアップです。これは、オンラインリビジョンクリーンアップのクリーンアップ段階に対応しています。 プライマリインスタンスでオンラインでのリビジョンクリーンアップが実行された後に、スタンバイインスタンスで自動クリーンアップが実行されます。
見積もりフェーズとコンパクションフェーズはスタンバイインスタンスでは実行されません。
オフラインでのリビジョンクリーンアップでは、オンラインでのリビジョンクリーンアップよりも多くのディスク領域を解放できますか。
オフラインでのリビジョンクリーンアップでは古いリビジョンをすぐに削除できますが、オンラインでのリビジョンクリーンアップでは、古いリビジョンが引き続きアプリケーションスタックによって参照されていることを考慮する必要があります。そのため、オフラインのほうがオンラインよりも積極的にガベージを削除できますが、ガベージコレクションサイクルを数回経ると、この効果は薄れます。
この章 の「オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合」の節も参照してください。
メモリマップファイル操作に関する考慮事項はありますか。
  • Windows環境では 、通常のファイルアクセスが常に適用されるので、メモリマップアクセスは使用されません。 一般的なアドバイスとして、使用可能なすべてのRAMをヒープに割り当て、segmentCacheサイズを増やす必要があります。 segmentCacheを増やすには、org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.configにsegmentCache.sizeオプションを追加します(例:segmentCache.size=20480)。 オペレーティングシステムや他のプロセス用のRAMを忘れないでください。
  • Windows 以外の環境 では、物理メモリのサイズを大きくすることで、リポジトリのメモリマップの効率性を向上できます。

オンラインでのリビジョンクリーンアップの監視

オンラインリビジョンのクリーンアップ中に監視する必要があるのは何ですか。
  • オンラインリビジョンクリーンアップが有効な場合は、ディスク領域を監視する必要があります。 ディスク領域が不十分な場合、クリーンアップは実行されないか、早期に終了します。
  • ログで、オンラインリビジョンクリーンアップの完了時間を確認します。 これは 2 時間以下である必要があります。
  • チェックポイントの数。 コンパクションの実行時にチェックポイントが 4 つ以上ある場合は、チェックポイントをクリーンアップすることをお勧めします。
オンラインリビジョンのクリーンアップが正常に完了したかどうかを確認する方法
オンラインリビジョンのクリーンアップが正常に完了したかどうかを確認するには、ログを確認します。
例えば、「 TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles 」は、圧縮手順が正常に完了したことを意味します。前に「 TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles 」というメッセージが付いていない場合は、同時負荷が大きすぎることを意味します。
それに対応して、クリーンアップ手順が正常に完了 TarMK GC #{}: cleanup completed in {} ({} ms したことを示すメッセージ「」が表示されます。
最後のオンラインリビジョンクリーンアップ実行の統計はどこで見つかりますか?
ステータス、進行状況および統計は、JMX( SegmentRevisionGarbageCollection MBean)を介して公開されます。 MBeanの詳細については、 SegmentRevisionGarbageCollection 次の段落を参照し てください
進行状況は、 EstimatedRevisionGCCompletion SegmentRevisionGarbageCollection MBean.
MBeanのリファレンスは、を使用して取得できます ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”
統計は、最後のシステム起動以降にのみ利用できます。 外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。外部監 視ツールの例として、Nagiosにヘルスチェックを添付する方法については、AEMのドキュメントを参照してください
関連するログエントリとは
  • オンラインリビジョンのクリーンアップが開始/停止しました
    • オンラインリビジョンのクリーンアップは、次の3つのフェーズで構成されます。推定、圧縮、クリーンアップ。 リポジトリに十分な量のガベージが含まれていない場合は、見積もりによってコンパクションとクリーンアップがスキップされることがあります。最新バージョンのAEMでは、「 TarMK GC #{}: estimation started 」というメッセージは推定の開始を示し、「 TarMK GC #{}: compaction started, strategy={} 」は圧縮の開始を示し、「T arMK GC #{}: cleanup started. Current repository size is {} ({} bytes 」はクリーンアップの開始を示します。
  • リビジョンのクリーンアップによって取得されたディスク領域
    • 領域は、クリーンアップフェーズが完了した場合にのみ再利用されます。 クリーンアップ段階の完了は、ログメッセージ「T arMK GC #{}: cleanup completed in {} ({} ms 」で示されます。 クリーンアップ後のサイズは {}({} バイト)で、再利用された領域は {}({} バイト)です。コンパクションマップの重み付け/深さは {}/{}({} バイト/{})です。
  • リビジョンのクリーンアップ中に問題が発生しました
    • 多くのエラー状態があり、それらすべてが「TarMK GC」で始まるWARNまたはERRORログメッセージでマークされます。
後述の「エラーメッセージに基づ くトラブルシューティング 」の節も参照してください。
オンラインリビジョンのクリーンアップが完了した後に、空き領域がいくつ増えたかを確認する方法 クリーンアップサイクルの最後に、ログに次のメッセージが含まれています。「 TarMK GC #3: cleanup completed 」。リポジトリのサイズと再生済みガベージの量を含みます。
オンラインリビジョンのクリーンアップが完了した後、リポジトリの整合性を確認する方法を教えてください。
オンラインリビジョンのクリーンアップ後にリポジトリの整合性チェックは必要ありません。
ただし、クリーンアップ後にリポジトリのステータスを確認するには、次の操作を実行します。
オンラインリビジョンのクリーンアップに失敗したかどうかを検出する方法と、回復する手順を教えてください。 失敗状態は、「TarMK GC」で始まるWARNまたはERRORログメッセージで示されます。 後述の「エラーメッセージに基づ くトラブルシューティング 」の節も参照してください。
リビジョンクリーンアップのヘルスチェックで公開される情報 ステータスレベルの色分けとの対応も教えてください。
リビジョンのクリーンアップヘルスチェックは、操作ダッシュボ ードの一部です
オンラインリビジョンク リーンアップメンテナンスタスクの最後の実行が正常に完了した場合、ステータスはGREENになります。
オンラインリビジョンク リーンアップのメンテナンスタスクが 1回キャンセルされた場合は、黄色になります。
オンラインリビジョン クリーンアップのメンテナンスタスクが 3回連続でキャンセルされた場合は、REDになります。 この場合、手動操作が必要になるか 、オンラインリビジョンのクリーンアップが再び失敗する可能性があります。 詳しくは、以下の「トラブルシューティング 」を参照 してください。
また、システムを再起動した後に、ヘルスチェックの状態がリセットされることにも注意してください。 そのため、新たに再起動されたインスタンスでは、リビジョンクリーンアップヘルスチェックで緑色のステータスが示されます。外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。外部監 視ツールの例として、Nagiosにヘルスチェックを添付する方法については、AEMのドキュメントを参照してください
スタンバイインスタンスの自動クリーンアップを監視する方法
ステータス、進行状況および統計は、MBXeanを使用してJMX経由で公開さ SegmentRevisionGarbageCollection れます。 以下の Oakのドキュメントも参照してください
MBeanの参照は、を使用して取得できます ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”
統計は、最後のシステム起動以降にのみ利用できます。 外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。また、外部監視ツールの例と して、Nagiosにヘルスチェックを添付する方法については、AEMのドキュメントを参照してください
ログファイルを使用して、自動クリーンアップの状態、進行状況、および統計を確認することもできます。
スタンバイ・インスタンスで自動クリーンアップ中に監視する必要があるのは何ですか。
  • 自動クリーンアップを実行する際は、ディスク領域を監視する必要があります。
  • 完了時間(ログ経由)。2時間を超えないようにします。
  • 自動クリーンアップの実行後のセグメントストアのサイズ。 スタンバイインスタンスでのセグメントストアのサイズは、プライマリインスタンスでのサイズとほぼ同じである必要があります。

オンラインでのリビジョンクリーンアップのトラブルシューティング

オンラインでのリビジョンクリーンアップを実行しない場合に起こり得る最悪の状況は何ですか。 AEM インスタンスのディスク領域が不足し、実稼動が停止します。
パブリッシュインスタンスでオンラインでのリビジョンクリーンアップを実行する場合、ユーザートラフィックが多いことは問題になりますか。 ユーザートラフィックが多いと、コンパクションフェーズを正常に完了できるかどうかに影響します。
ヘルスチェックおよびログエントリによると、オンラインでのリビジョンクリーンアップは 3 回連続で正常に完了していません。オンラインでのリビジョンクリーンアップを正常に完了させるには、何が必要ですか。 問題を検出して修正するには、以下の手順を実行します。
  • まず、ログエントリを確認します。
  • ログの情報に基づいて、適切な操作を実行します。
    • If the logs show five missed compact cycles and a timeout on the forceCompact cycle, schedule the maintenance window to a quiet time when the amount of repository writes is low. You can check repository writes in the repositoy metrics monitoring tool located at https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
    • メンテナンスウィンドウの終わりにクリーンアップが停止した場合は、メンテナンスタスクのユーザーインターフェイスで、メンテナンスウィンドウの長さの設定が十分であることを確認してください。
    • 使用可能なヒープメモリが不足している場合は、インスタンスに十分なメモリがあることを確認してください。
    • 応答が遅い場合は、セグメントストアが大きくなりすぎて、メンテナンスウィンドウを長くしてもオンラインでのリビジョンクリーンアップを完了できない可能性があります。例えば、先週、オンラインでのリビジョンクリーンアップが一度も正常に完了してない場合は、セグメントストアを対処可能なサイズに戻すために、オフラインでのメンテナンスを計画し、オフラインでのリビジョンクリーンアップを実行することをお勧めします。
ヘルスチェックアラートがオンになった場合、何をする必要がありますか。 この前の項目を参照してください。
スケジュールされたメンテナンスウィンドウ中にオンラインでのリビジョンクリーンアップが時間切れになった場合、どうなりますか。 オンラインでのリビジョンクリーンアップはキャンセルされ、残りの手順は削除されます。メンテナンスウィンドウが次回スケジュールされたときに、クリーンアップが再度開始されます。
What is causing SegmentNotFoundException instances to be logged in the error.log and how can I recover?
A SegmentNotFoundException is logged by the TarMK when it tries to access a storage unit (a segment) that it can not find. 次の 3 つのシナリオで、この問題が発生する可能性があります。
  1. アプリケーションが、推奨されるアクセス方法(Sling や JCR API など)を使用せずに、下位レベルの API/SPI を使用してリポジトリにアクセスし、セグメントの保持時間を超えている場合。つまり、アプリケーションがオンラインでのリビジョンクリーンアップで許可される保持時間(デフォルトは 24 時間)よりも長くエンティティへの参照を保持している場合です。この状況は一時的で、データの破損にはつながりません。回復するには、oak-runツールを使用して、例外の一時的な性質を確認する必要があります(oak-runチェックでエラーが報告されないようにしてください)。 これを行うには、インスタンスをオフラインにして、後で再起動する必要があります。
  2. 外部イベントによってディスクのデータが破損している場合。これは、ディスクの障害、ディスク領域の不足または必要なデータファイルが誤って変更されたことが原因である可能性があります。この場合は、インスタンスをオフラインにして、oak-run チェックを使用して修復する必要があります。For more details on how to perform the oak-run check, read the following Apache documentation .
  3. All other occurrences should addressed through the Adobe Customer Care .

エラーメッセージに基づくトラブルシューティング

オンラインリビジョンのクリーンアッププロセス中にインシデントが発生した場合、error.logは詳細になります。 以下のマトリックスでは、最も一般的なメッセージを説明し、解決策を示しています。
フェーズ
ログメッセージ
説明
次の手順
見積
TarMK GC #2:圧縮が一時停止されたため、推定がスキップされました
構成によりシステム上で締め固めを無効にした場合、推定段階はスキップされる。
オンラインでのリビジョンクリーンアップの有効化.
TarMK GC #2:見積もりが中断されました:$。 Skipping compaction.
見積フェーズが途中で終了しました。 見積もりフェーズを中断させる可能性があるイベントの例としては、ホストシステムでのメモリ不足やディスク領域の不足があります。
与えられた理由に依存する。
圧縮
TarMK GC #2:締め付け一時停止
コンフィギュレーションにより締め固め段階が一時停止される限り、推定段階も締め固め段階も実行されない。
オンラインリビジョンのクリーンアップを有効にします。
TarMK GC #2:圧縮がキャンセルされました:$。
圧縮フェーズが途中で終了しました。 コンパクションフェーズを中断させる可能性があるイベントの例としては、ホストシステムでのメモリ不足やディスク領域の不足があります。また、圧縮は、システムをシャットダウンするか、Operations Dashboard内のMaintenance windowなどの管理インターフェイスを使用して明示的にキャンセルすることでもキャンセルできます。
与えられた理由に依存する。
TarMK GC #2:5サイクル後、32.902分(1974140ミリ秒)で圧縮に失敗しました。
このメッセージは、回復できないエラーが発生したとは限りませんが、特定の試行の後に圧縮が終了したことを意味します。 また、次の段落を読 んでください
次の Oakのドキュメント 、および「オンラインリビジョンのクリーンアップを実行 中」の最後の質問を読みます
クリーンアップ
TarMK GC #2:浄化中断
リポジトリをシャットダウンすることでクリーンアップが取り消されました。 整合性への影響はありません。また、多くの場合、ディスク領域は完全には再利用されません。残りの領域は、次のリビジョンクリーンアップサイクルで再利用されます。
リポジトリがシャットダウンされた理由を調べ、メンテナンス期間中にリポジトリがシャットダウンされないように試みます。

オフラインでのリビジョンクリーンアップの実行方法

AEM のインストールで使用する Oak バージョンに応じて、異なるバージョンの Oak-run ツールを使用する必要があります。ツールを使用する前に、以下のバージョン要件を確認してください。
  • For Oak versions 1.0.0 through 1.0.11 or 1.1.0 through 1.1.6 , use Oak-run version​ 1.0.11
  • 上述のものよりも新しい Oak バージョンについては、AEM インストールの Oak コアと一致するバージョンの oak-run を使用します。
Adobe provides a tool called Oak-run for performing revision cleanup. このツールは以下のページでダウンロードできます。
このツールは、リポジトリのコンパクションを実行するために手動で実行できる実行可能 jar です。このプロセスはオフラインでのリビジョンクリーンアップと呼ばれます。これは、ツールを適切に実行するためにリポジトリをシャットダウンする必要があるためです。メンテナンスウィンドウに合わせてクリーンアップを計画してください。
For tips on how to increase the performance of the cleanup process, see Increasing the Performance of Offline Revision Cleanup .
メンテナンスが発生する前に、古いチェックポイントを削除することもできます(後述の手順 2 および 3)。これは、チェックポイントが 100 個を超えるインスタンスにのみ推奨されます。
  1. AEM インスタンスの最新バックアップがあることを必ず確認します。
    AEM をシャットダウンします。
  2. (オプション)ツールを使用して古いチェックポイントを探します。
    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
    
  3. (オプション)次に、参照されていないチェックポイントを削除します。
    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
    
  4. コンパクションを実行して完了するまで待ちます。
    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
    
    

オフラインでのリビジョンクリーンアップのパフォーマンスの向上

oak-run ツールには、リビジョンクリーンアッププロセスのパフォーマンスを向上させ、メンテナンスウィンドウをできる限り最短化するための複数の機能が導入されています。
このような機能には、以下に示すコマンドラインパラメーターが含まれます。
  • -mmap。 これは、trueまたはfalseに設定できます。 true に設定すると、メモリマップアクセスが使用されます。false に設定すると、ファイルアクセスが使用されます。指定しない場合、64 ビットシステムではメモリマップアクセスが、32 ビットシステムではファイルアクセスが使用されます。Windows では通常のファイルアクセスが常に強制的に利用されるので、このオプションは無視されます。 このパラメーターは、-Dtar.memoryMappedパラメーターに置き換えられました。
  • -Dupdate.limit 。一時トランザクションをディスクにフラッシュするためのしきい値を定義します。デフォルト値は 10000 です。
  • -Dcompress-interval 。現在のマップを圧縮するまで保持するコンパクションマップエントリの数です。デフォルトは、1000000 です。十分なヒープメモリが使用可能な場合は、スループットを高速化するために、この値をさらに大きい数に増やします。 このパラメーターは Oak バージョン 1.6 で削除され、効果はありません。
  • -Dcompaction-progress-log 。ログに記録される、コンパクションされたノードの数です。デフォルト値は150000で、操作中に最初の150000圧縮されたノードがログに記録されます。 このパラメーターは、次に示すパラメーターとともに使用します。
  • -Dtar.PersistCompactionMap。 圧縮マップの永続性にヒープメモリの代わりにディスク領域を使用する場合は、このパラメーターをtrueに設定します。 Requires the oak-run tool versions 1.4 and higher. 詳しくは、 オフラインでのリビジョンクリーンアップに関するよくある質問 の節の質問 3 を参照してください。 このパラメーターは Oak バージョン 1.6 で削除され、効果はありません。
  • --force. 圧縮を強制し、一致しないセグメントストアのバージョンを無視します。
Using the --force parameter will upgrade the segment store to the latest version, which is incompatible with older Oak versions. また、ダウングレードができなくなる点に注意してください。原則として、これらのパラメーターは、使用方法について確実に把握している場合にのみ慎重に使用してください。
パラメーターの使用例を示します。
java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

リビジョンクリーンアップをトリガーするその他の方法

前述の方法に加えて、以下のように JMX コンソールを使用してリビジョンクリーンアップのメカニズムをトリガーすることもできます。
  1. http://localhost:4502/system/console/jmx にアクセスして JMX コンソールを開きます。
  2. RevisionGarbageCollection MBean をクリックします。
  3. 次のウィンドウで、 startRevisionGC() をクリックし、 起動 ​して、リビジョンのガベージコレクションジョブを開始します。

オフラインでのリビジョンクリーンアップに関するよくある質問

オフラインでのリビジョンクリーンアップの時間に作用する要因は何ですか。
クリーンアップの実行時間は、リポジトリサイズとクリーンアップする必要があるリビジョンの数によって決まります。
リビジョンとページバージョンの違いは何ですか。
  • Oakリビジョン:Oakは、すべてのコンテンツをノードとプロパティで構成される大きなツリー階層に編成します。 このコンテンツツリーの各スナップショットまたはリビジョンは不変で、ツリーに対する変更は一連の新しいリビジョンとして表されます。通常は、コンテンツが変更されるたびに新しいリビジョンがトリガーされます。「リンク先を表示 」も参照
  • ページバージョン:バージョン管理は、特定の時点でのページの「スナップショット」を作成します。 通常は、ページがアクティベートされたときに新しいバージョンが作成されます。For more information, see Working with Page Versions .
オフラインでのリビジョンクリーンアップのタスクが 8 時間以内に完了しない場合に、このタスクを高速化するにはどうすればよいですか。 If the revision task does not complete within 8 hours and the thread dumps reveal that the main hotspot is InMemoryCompactionMap.findEntry , use the following parameter with the oak-run tool versions 1.4 or higher: -Dtar.PersistCompactionMap=true . Be aware that the -Dtar.PersistCompactionMap parameter has been removed in Oak version 1.6.