リビジョンクリーンアップ revision-cleanup

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

はじめに introduction

リポジトリが更新されるたびに、新しいコンテンツのリビジョンが作成されます。その結果、更新のたびにリポジトリのサイズが大きくなります。制御できないリポジトリの増加を避けるには、古いリビジョンをクリーンアップして、ディスクリソースを解放する必要があります。 このメンテナンス機能は、リビジョンクリーンアップと呼ばれます。AEM 6.0 以降、オフラインルーチンとして使用可能になりました。

AEM 6.3 では、この機能のオンラインバージョンであるオンラインでのリビジョンクリーンアップが導入されました。 オフラインのリビジョンクリーンアップでは AEM インスタンスをシャットダウンする必要があるのに対し、オンラインのリビジョンクリーンアップでは AEM インスタンスがオンラインの間に実行できます。オンラインのリビジョンクリーンアップはデフォルトでオンになっており、リビジョンのクリーンアップを実行する方法として推奨されます。

メモ:オンラインでのリビジョンクリーンアップの概要および使用方法について詳しくは、ビデオを参照してください

リビジョンクリーンアップのプロセスは、見積もりコンパクションクリーンアップ ​の 3 つのフェーズで構成されます。見積もりフェーズでは、収集されるガベージの量に基づいて、次のフェーズ(コンパクション)を実行するかどうかが判断されます。コンパクションフェーズでは、未使用のコンテンツを除いて、セグメントと tar ファイルが書き換えられます。その後のクリーンアップフェーズでは、ガベージも含めて、古いセグメントが削除されます。通常、オフラインモードではより多くの領域を再利用できます。これは、オンラインモードでは、追加のセグメントを収集しないようにする AEM の作業セットを考慮する必要があるからです。

リビジョンクリーンアップについて詳しくは、次のリンクを参照してください。

また、Oak の公式ドキュメント も参考になります。

オフラインでのリビジョンクリーンアップではなく、オンラインのリビジョンクリーンアップを使用する場合 when-to-use-online-revision-cleanup-as-opposed-to-offline-revision-cleanup

リビジョンのクリーンアップを実行する場合は、オンラインでのリビジョンクリーンアップをお勧めします。 オフラインでのリビジョンクリーンアップは、例外的な場合にのみ使用してください。例えば、新しいストレージ形式に移行する前や、アドビカスタマーケアから依頼された場合です。

オンラインでのリビジョンクリーンアップの実行方法 how-to-run-online-revision-cleanup

オンラインでのリビジョンクリーンアップは、AEM のオーサーインスタンスとパブリッシュインスタンスの両方で、1 日に 1 回自動的に実行されるようにデフォルトで設定されています。必要な操作は、ユーザーアクティビティが最も少ない時間帯に、メンテナンスウィンドウを定義することだけです。オンラインでのリビジョンクリーンアップタスクは、次のように設定します。

  1. メイン AEM ウィンドウで、ツール/運営/ダッシュボード/メンテナンス ​に移動するか、ブラウザーで https://serveraddress:serverport/libs/granite/operations/content/maintenance.html を指定してください。

    chlimage_1-90

  2. 日別メンテナンスウィンドウ ​にマウスポインターを置き、「設定」アイコンをクリックしてください。

    chlimage_1-91

  3. 必要な値(繰り返し、開始時刻、終了時刻)を入力し、「保存」をクリックします。

    chlimage_1-92

または、リビジョンクリーンアップのタスクを手動で実行する場合は、次の手順を実行します。

  1. ツール/運営/ダッシュボード/メンテナンス ​に移動するか、https://serveraddress:serverport/libs/granite/operations/content/maintenance.html を直接参照してください。

  2. 日別メンテナンスウィンドウ ​をクリックします。

  3. リビジョンクリーンアップ のアイコンにマウスポインターを置きます。

  4. 実行」をクリックします。

    chlimage_1-93

オフラインでのリビジョンクリーンアップ後のオンラインでのリビジョンクリーンアップの実行 running-online-revision-cleanup-after-offline-revision-cleanup

リビジョンクリーンアップのプロセスでは、古いリビジョンが世代ごとに再利用されます。つまり、リビジョンクリーンアップを実行するたびに、新しい世代が作成されてディスクに保持されます。ただし、リビジョンクリーンアップにはオフラインとオンラインの 2 種類があり、オフラインでのリビジョンクリーンアップは 1 つの世代を保持し、オンラインでのリビジョンクリーンアップは 2 つの世代を保持するという違いがあります。そのため、オフラインでのリビジョンクリーンアップを実行した​ にオンラインでのリビジョンクリーンアップを実行した場合は、以下のようになります。

  1. オンラインでのリビジョンクリーンアップを初めて実行した後は、リポジトリのサイズが 2 倍になります。これは、ディスク上に 2 つの世代が保持されるからです。
  2. その後の実行では、新しい世代が作成されるときに一時的にリポジトリのサイズが大きくなりますが、オンラインでのリビジョンクリーンアッププロセスにより以前の世代が再利用されるので、初めて実行した後のサイズで落ち着きます。

また、コミットの種類と数に応じて、各世代のサイズが以前の世代と異なる場合があるため、最終的なサイズは実行によって異なる可能性があります。

そのため、当初予測していたたリポジトリサイズよりも、少なくとも 2 倍または 3 倍大きなディスクサイズにすることをお勧めします。

フルコンパクションモードとテールコンパクションモード full-and-tail-compaction-modes

AEM 6.4 では、オンラインでのリビジョンクリーンアッププロセスの​ コンパクション ​フェーズ用に 2 つの新しいモード ​が導入されています。

  • フルコンパクション ​モードでは、リポジトリ全体のすべてのセグメントと tar ファイルが書き換えられます。そのため、後続のクリーンアップフェーズでは、リポジトリ全体で最大量のガベージを削除できます。フルコンパクションはリポジトリ全体に影響を与えるので、実行するには大量のシステムリソースと時間が必要です。フルコンパクションは、AEM 6.3 のコンパクションフェーズに対応します。
  • テールコンパクション ​モードでは、リポジトリ内の最新のセグメントと tar ファイルのみが書き換えられます。最新のセグメントと tar ファイルは、フルコンパクションまたはテールコンパクションが最後に実行された後に追加されたものです。そのため、後続のクリーンアップフェーズでは、リポジトリの最新の部分に含まれるガベージのみを削除できます。テールコンパクションはリポジトリの一部にのみ影響するので、完了するために必要なシステムリソースと時間がフルコンパクションよりも大幅に少なくなります。

これらのコンパクションモードでは、効率とリソース消費がトレードオフされます。テールコンパクションは効果が低いものの、通常のシステム運用に対する影響も少なくなります。一方、フルコンパクションはより効果的ですが、通常のシステム運用に大きな影響を与えます。

また、AEM 6.4 では、コンパクション時のより効率的なコンテンツの重複除外メカニズムが導入されました。これにより、リポジトリのディスク上のフットプリントがさらに削減されます。

次の 2 つの図は、AEM 6.3 と比較した AEM 6.4 の平均実行時間とディスク上の平均フットプリントの減少を示す社内ラボでのテスト結果を示しています。

onrc-duration-6_4vs63 segmentstore-6_4vs63

フルコンパクションおよびテールコンパクションの設定方法 how-to-configure-full-and-tail-compaction

デフォルト設定では、テールコンパクションを平日に、フルコンパクションを日曜日に実行します。デフォルト設定は、RevisionCleanupTask  メンテナンスタスク の新しい設定値 full.gc.days を使用することで変更できます。

full.gc.days 値を設定する場合、フルコンパクションは値で定義された日に実行され、テールコンパクションは値で定義されていない日に実行されることにご注意ください。例えば、フルコンパクションを日曜日に実行するように設定した場合、テールコンパクションは月曜日から土曜日に実行されます。例えば、フルコンパクションを毎日実行するように設定した場合、テールコンパクションはまったく実行されません。

また、以下の点に留意してください。

  • テールコンパクション ​は効果が低いものの、通常のシステム運用に対する影響が少ない。そのため、営業日に実行することが想定されている。
  • フルコンパクション ​はより効果的なものの、通常のシステム運用に大きな影響を与える。そのため、営業日以外に使用することが想定されている。
  • テールコンパクションとフルコンパクションはいずれも、ピーク時を避けて実行するようにスケジュールする必要がある。

トラブルシューティング troubleshooting

新しいコンパクションモードを使用する場合は、次の点に注意してください。

  • 入出力(I/O)アクティビティ(I/O 操作、CPU の I/O 待機 、コミットキューサイズなど)を監視できます。これは、システムが I/O バウンドしているかどうか、アップサイジングが必要かどうかを判断するのに役立ちます。
  • RevisionCleanupTaskHealthCheck は、オンラインでのリビジョンクリーンアップの全体的なヘルスステータスを示します。AEM 6.3 と同様に機能し、フルコンパクションとテールコンパクションは区別されません。
  • ログメッセージには、コンパクションモードについての関連情報が記録されます。例えば、オンラインでのリビジョンクリーンアップが開始されると、対応するログメッセージにコンパクションモードが表示されます。また、場合によっては、テールコンパクションの実行がスケジュールされていると、システムがフルコンパクションに戻り、ログメッセージにこの変更が示されることがあります。以下のログのサンプルは、コンパクションモードとテールコンパクションからフルコンパクションへの変更を示しています。
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

既知の制限事項 known-limitations

テールコンパクションモードとフルコンパクションモードを切り替えると、クリーンアッププロセスが遅れる場合があります。より正確には、フルコンパクションの後にリポジトリが増えます(サイズが 2 倍になります)。リポジトリがフルコンパクション前のサイズより小さくなると、余分なスペースは後続のテールコンパクションで再利用されます。メンテナンスタスクの並列実行も避ける必要があります。

最初に予測したリポジトリサイズよりも少なくとも 2 倍または 3 倍大きなディスクサイズにすることをお勧めします。

オンラインでのリビジョンクリーンアップに関するよくある質問 online-revision-cleanup-frequently-asked-questions

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

質問
回答
AEM 6.4 にアップグレードするときの注意点を教えてください。

TarMK の永続性形式が AEM 6.4 で変更されます。これらの変更には、事前の移行手順は必要ありません。既存のリポジトリは、周期的な移行を実行します。これはユーザーに対して透過的です。AEM 6.4(または関連ツール)がリポジトリに初めてアクセスすると、移行プロセスが開始されます。

AEM 6.4 永続性形式への移行が開始されると、リポジトリを以前の AEM 6.3 永続性形式に戻すことはできなくなります。

Oak Segment Tar への移行 migrating-to-oak-segment-tar

質問
回答
リポジトリを移行する必要があるのはなぜですか。

AEM 6.3 で、特にオンラインでのリビジョンクリーンアップのパフォーマンスと効果を高めるために、ストレージ形式の変更が必要となりました。これらの変更は後方互換性がなく、古い Oak セグメント(AEM 6.2 以前)で作成されたリポジトリは移行する必要があります。

ストレージ形式を変更するその他メリットは次のとおりです。

以前の Tar 形式もサポートされますか。
AEM 6.3 では、新しい OAK Segment Tar のみがサポートされます。
コンテンツの移行は常に必須ですか。
はい。新しいインスタンスから始めない限り、常にコンテンツを移行する必要があります。
6.3 にアップグレードしてから、(例えば、別のメンテナンスウィンドウを使用して)後で移行を実行できますか。
できません。前述のとおり、コンテンツの移行は必須です。
移行時のダウンタイムは回避できますか。
いいえ。これは、実行中のインスタンスでは行えない 1 回限りの作業です。
誤って不適切なリポジトリ形式に対して移行を実行した場合はどうなりますか。
oak-segment-tar リポジトリに対して oak-segment モジュール(またはその逆)を実行しようとすると、起動が失敗し、「Invalid segment format(セグメント形式が無効です)」というメッセージが表示されて、IllegalStateException が発生します。データが破損することはありません。
検索インデックスの再作成は必要ですか。
いいえ。oak-segment から oak-segment-tar への移行によって、コンテナ形式が変更されます。含まれているデータに影響はなく、データは変更されません。
移行中および移行後に必要と予想されるディスク領域を計算する最適な方法を教えてください。
この移行は、セグメントストアを新しい形式で再作成することに相当します。これは、移行中に必要な追加のディスク容量を見積もるために使用できます。古いセグメントストアは移行後に削除して、領域を再利用することができます。
移行時間の最適な見積もり方法を教えてください。
移行前にオフラインでのリビジョンクリーンアップを実行すると、移行のパフォーマンスを大幅に高めることができます。アップグレードプロセスの前提条件として、オフラインでのリビジョンクリーンアップを実行することをすべての顧客にお勧めします。一般に移行時間は、オフラインでのリビジョンクリーンアップタスクが移行前に実行されていると仮定して、オフラインでのリビジョンクリーンアップ時間と同程度です。

オンラインでのリビジョンクリーンアップの実行 running-online-revision-cleanup

質問
回答
オンラインでのリビジョンクリーンアップは、どのくらいの頻度で実行する必要がありますか。
1 日に 1 回。これは、操作ダッシュボードのデフォルトの設定です。
オンラインでのリビジョンクリーンアップのメンテナンスタスクを開始する時間を設定する方法を教えてください。
オンラインでのリビジョンクリーンアップの実行方法 の節を参照してください。
オンラインでのリビジョンクリーンアップには、超過するべきではない実行頻度の上限がありますか。
オンラインでのリビジョンクリーンアップは、デフォルト設定のとおり、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 時間以下です。
オンラインでのリビジョンクリーンアップにそれよりも長い時間がかかる場合はどうすればよいですか。
  • クリーンアップが毎日実行されていることを確認してください。
  • 操作ダッシュボードでメンテナンスウィンドウを適切に設定して、リポジトリのアクティビティが最も少ない時間帯にクリーンアップが実行されるようにしてください。
  • システムリソース(CPU、メモリ、I/O)を拡張してください。
設定したメンテナンスウィンドウ中にオンラインでのリビジョンクリーンアップが終わらない場合は、何が起きていますか。
他のメンテナンスタスクによって、その実行が遅延されないようにしてください。これは、同じメンテナンスウィンドウ内で、オンラインでのリビジョンクリーンアップよりも多くのメンテナンスタスクが実行された場合に発生する可能性があります。なお、メンテナンスタスクは順番に実行されます。順番は変更できません。
リビジョンのガベージコレクションがスキップされるのはなぜですか。

リビジョンクリーンアップでは見積もりフェーズで、クリーンアップするのに十分なガベージがあるかどうかを判断します。見積もりでは、最後のコンパクション後のリポジトリのサイズと現在のサイズが比較されます。サイズが設定された差分を超えると、クリーンアップが実行されます。サイズの差分は 1 GB に設定されています。これは、リポジトリーのサイズが前回のクリーンアップの実行から 1 GB 増加しなかった場合、新しいリビジョンのクリーンアップの反復がスキップされることを事実上意味します。

見積もりフェーズに関連するログエントリは以下のとおりです。

  • リビジョンの GC が実行される:サイズ差分は N% または N/N(N/N バイト)であるため、コンパクションを実行
  • リビジョンの GC が実行 されないサイズ差分は N% または N/N(N/N バイト)であるため、とりあえずコンパクションをスキップ
パフォーマンスへの影響が大きすぎる場合に、自動コンパクションを安全に中止できますか。
はい。AEM 6.3 以降では、操作ダッシュボード内のメンテナンスタスクウィンドウまたは JMX から安全に停止できます。
スケジュールされたクリーンアップタスクの実行中に AEM インスタンスがシャットダウンされた場合、プロセスは安全に中止されますか。またはコンパクションが終了するまでシャットダウンがブロックされますか。
リビジョンクリーンアップが中断され、リポジトリは安全にシャットダウンされます。
オンラインでのリビジョンクリーンアップ中にシステムがクラッシュした場合はどうなりますか。
このような場合にデータが破損するリスクはありません。残ったガベージは、その後の実行でクリーンアップされます。
オンラインでのリビジョンクリーンアップを実行しないと、どのような影響がありますか。
時間の経過に伴いパフォーマンスが低下します。
どのリビジョンが収集されますか。
デフォルトでは、オンラインでのリビジョンクリーンアップで収集されるのは 24 時間以上前のリビジョンのみです。
リポジトリへの同時書き込みからの干渉が多すぎる場合はどうなりますか。

同時書き込みが可能なシステムでは、コンパクションサイクルの終了時に変更をコミットできるように、オンラインでのリビジョンクリーンアップで排他書き込みアクセスが必要になる場合があります。システムは forceCompact モード になります。詳細に関しては、oak のドキュメントを参照してください。強制コンパクションでは、同時書き込みの干渉を受けずに最終的に変更をコミットするために、排他的な書き込みロックが取得されます。応答時間に対する影響を制限するために、タイムアウト値を定義できます。この値はデフォルトで 1 分に設定されています。つまり、1 分以内に強制コンパクションが完了しない場合は同時コミットが優先され、コンパクションプロセスは中止されます。

強制コンパクションの実行時間は以下の要素によって変動します。

  • ハードウェア:特に IOPS。IOPS が増えるにつれ、処理時間が短くなります。
  • セグメントストアのサイズ:時間はセグメントストアのサイズと共に長くなります。
スタンバイインスタンスでは、オンラインでのリビジョンクリーンアップはどのように実行されますか。

コールドスタンバイセットアップでは、オンラインでのリビジョンクリーンアップの実行を設定する必要があるのは、プライマリインスタンスのみです。スタンバイインスタンスで、オンラインでのリビジョンクリーンアップを明示的にスケジュールする必要はありません。

スタンバイインスタンスでの対応する操作は自動クリーンアップです。これは、オンラインでのリビジョンクリーンアップのクリーンアップフェーズに相当します。自動クリーンアップは、プライマリインスタンスでオンラインリビジョンクリーンアップが実行された後、スタンバイインスタンスで実行されます。

見積もりフェーズとコンパクションフェーズは、スタンバイインスタンスでは実行されません。

オフラインでのリビジョンクリーンアップでは、オンラインでのリビジョンクリーンアップよりも多くのディスク領域を解放できますか。

オフラインでのリビジョンクリーンアップでは、古いリビジョンを即座に削除できますが、オンラインでのリビジョンクリーンアップでは、アプリケーションスタックによって参照されている古いリビジョンを考慮する必要があります。 そのため、前者は後者よりも積極的にガベージを削除することができ、数回のガベージ収集サイクルで効果が表れます。

この章の「オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合」の節も参照してください。

メモリマップファイル操作に関する考慮事項はありますか。
  • Windows 環境 では、通常のファイルアクセスが常に強制的に利用されるので、メモリマップアクセスは使用されません。一般的に、利用可能なすべての RAM をヒープに割り当て、segmentCache サイズを大きくする必要があります。segmentCache のサイズは、org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config に segmentCache.size オプションを追加して大きくします(例:segmentCache.size=20480)。オペレーティングシステムや他のプロセス用に、一定の RAM を残しておいてください。
  • Windows 以外の環境 では、物理メモリのサイズを大きくすることで、リポジトリのメモリマップの効率性を向上できます。

オンラインでのリビジョンクリーンアップの監視 monitoring-online-revision-cleanup

オンラインでのリビジョンクリーンアップ中に監視する必要があるものは何ですか。
  • オンラインでのリビジョンクリーンアップが有効な場合は、ディスクスペースを監視する必要があります。ディスク領域が不十分な場合、クリーンアップは実行されないか、早期に終了します。
  • オンラインでのリビジョンクリーンアップの完了時間をログで確認してください。これは 2 時間以下である必要があります。
  • チェックポイントの数。コンパクションの実行時にチェックポイントが 3 つ以上ある場合は、チェックポイントをクリーンアップすることをお勧めします。
オンラインでのリビジョンクリーンアップが正常に完了したかどうかを確認する方法を教えてください。

オンラインでのリビジョンクリーンアップが正常に完了したかどうかは、ログを確認して確認できます。

例:「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)経由で表示されます。SegmentRevisionGarbageCollection MBean の詳細に関しては、次の段落 を参照してください。

進行状況は、 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={}」はコンパクションの開始を示し、「TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes」はクリーンアップの開始を示します。
  • リビジョンのクリーンアップで取得したディスクスペース
    • スペースは、クリーンアップフェーズが完了した場合にのみ再利用されます。クリーンアップフェーズの完了は、ログメッセージ「TarMK GC #{}: cleanup completed in {} ({} ms」で示されます。クリーンアップ後のサイズは {}({} バイト)で、再利用された領域は {}({} バイト)です。コンパクションマップの重み/深さは {}/{} ({} バイト/{})です。"
  • リビジョンのクリーンアップ中に問題が発生しました
    • 多くの失敗条件があり、すべての障害は、「TarMK GC」で始まる WARN または ERROR ログメッセージで示されます。

また、エラーメッセージに基づくトラブルシューティングの節を参照してください。

オンラインでのリビジョンクリーンアップが完了した後に、どのくらいのスペースが再利用されたかを確認する方法は?
クリーンアップサイクルの最後に、ログに「TarMK GC #3: cleanup completed」メッセージが表示されます。これにはリポジトリのサイズと再利用されたガベージの量も含まれます。
オンラインでのリビジョンクリーンアップが完了した後に、リポジトリの整合性を確認する方法を教えてください。

オンラインでのリビジョンクリーンアップの後は、リポジトリの整合性チェックは必要ありません。

ただし、クリーンアップ後にリポジトリのステータスを確認するには、次の操作を実行できます。

オンラインでのリビジョンクリーンアップが失敗したかどうかを検出する方法と、回復する手順を教えてください。
失敗条件は、「TarMK GC」で始まる WARN または ERROR ログメッセージで示されます。また、エラーメッセージに基づくトラブルシューティングの節を参照してください。
リビジョンクリーンアップのヘルスチェックではどのような情報が表示されますか。ステータスレベルの色分けとの対応も教えてください。

リビジョンのクリーンアップヘルスチェックは、 操作ダッシュボードの一部です。

オンラインでのリビジョンクリーンアップメンテナンスタスクの最後の実行が正常に完了した場合、ステータスは になります。

オンラインでのリビジョンクリーンアップのメンテナンスタスクが 1 回キャンセルされた場合、ステータスは イエロー になります。

オンラインでのリビジョンクリーンアップのメンテナンスタスクを 3 回連続でキャンセルした場合は、 になります。この場合、手動の操作が必要であるか、オンラインでのリビジョンクリーンアップが再び失敗する可能性が高くなります。詳細情報に関しては、以下のトラブルシューティングの節を参照してください。

システムの再起動後に、ヘルスチェックステータスがリセットされることにもご注意ください。そのため、新しく再起動したインスタンスは、リビジョンクリーンアップのヘルスチェックが緑色のステータスで表示されます。外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。外部の監視ツールの例として、Nagios にヘルスチェックを接続するための AEM のドキュメントを参照してください。

スタンバイインスタンスで自動クリーンアップを監視する方法を教えてください。

ステータス、進行状況および統計は、SegmentRevisionGarbageCollection MBean を使用し、JMX 経由で表示されます。次の Oak ドキュメントも参照してください。

MBean の参照は、ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection” を使用して取得できます。

確認できるのは、システムが最後に起動されて以降の統計情報のみであることにご注意ください。外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。また、 外部の監視ツールの例として、Nagios にヘルスチェックを接続するための AEM のドキュメントも参照してください。

ログファイルを使用して、自動クリーンアップのステータス、進行状況および統計情報を確認することもできます。

スタンバイインスタンスでの自動クリーンアップ中に監視する必要があるものは何ですか。
  • 自動クリーンアップの実行中は、ディスクスペースを監視する必要があります。
  • (ログを使用して)完了時間が 2 時間を超えていないことを確認します。
  • 自動クリーンアップが実行された後のセグメントストアサイズ。スタンバイインスタンスでのセグメントストアのサイズは、プライマリインスタンスでのサイズとほぼ同じである必要があります。

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

オンラインでのリビジョンクリーンアップを実行しない場合に起こり得る最悪の状況は何ですか。
AEM インスタンスのディスク領域が不足し、実稼動が停止します。
パブリッシュインスタンスでオンラインでのリビジョンクリーンアップを実行する場合、ユーザートラフィックが多いことは問題になりますか。
ユーザートラフィックが多いと、コンパクションフェーズを正常に完了できるかどうかに影響します。
ヘルスチェックおよびログエントリによると、オンラインでのリビジョンクリーンアップは 3 回連続で正常に完了していません。オンラインでのリビジョンクリーンアップを正常に完了させるには、何が必要ですか。

問題を見つけて修正するには、次の手順を実行します。

  • まず、ログエントリを確認します。

  • ログの情報に応じて、適切なアクションを実行します。

    • ログに、5 回の失敗したコンパクションサイクルとforceCompactサイクルでのタイムアウトが示されている場合は、リポジトリへの書き込みが少ない、処理が少ない時間帯にメンテナンスウィンドウをスケジュールします。リポジトリーへの書き込みは、https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html にあるリポジトリー指標の監視ツールで確認できます。
    • メンテナンスウィンドウの最後にクリーンアップが停止した場合は、メンテナンスタスクのユーザーインターフェイスでメンテナンスウィンドウの設定が十分に大きいことを確認してください
    • 使用可能なヒープメモリが不十分な場合は、インスタンスに十分なメモリがあることを確認します。
    • 反応が遅れるとセグメントストアが大きくなりすぎ、メンテナンスウィンドウが長くても、オンラインでのリビジョンクリーンアップを完了できない可能性があります。例えば、先週にオンラインでのリビジョンクリーンアップが正常に完了しなかった場合は、セグメントストアを管理可能なサイズに戻すために、オフラインでのメンテナンスを計画し、オフラインでのリビジョンクリーンアップを実行することをお勧めします。
ヘルスチェックアラートがオンになった場合、何をする必要がありますか。
この前の項目を参照してください。
スケジュールされたメンテナンスウィンドウ中にオンラインでのリビジョンクリーンアップが時間切れになった場合、どうなりますか。
オンラインでのリビジョンクリーンアップはキャンセルされ、残りは削除されます。メンテナンスウィンドウが次回スケジュールされると、再び開始されます。
SegmentNotFoundException インスタンスが error.log に記録される理由と復旧方法を教えてください。

SegmentNotFoundException は、TarMK がアクセスを試みたストレージユニット(セグメント)が見つからなかったときに、TarMK によってログに記録されます。この問題を引き起こす可能性のあるシナリオは次の 3 つです。

  1. 推奨されるアクセスメカニズム(Sling や JCR API など)を回避し、下位レベルの API/SPI を使用してリポジトリにアクセスし、セグメントの保持時間を超えるアプリケーション。つまり、オンラインでのリビジョンクリーンアップで許可されている保持時間(デフォルトでは 24 時間)より長い間、エンティティへの参照を保持します。このケースは一時的なもので、データの破損にはつながりません。復旧するには、oak-run ツールを使用して、この例外が一時的なものである(oak-run チェックでエラーが報告されない)ことを確認する必要があります。このためには、インスタンスをオフラインにし、後で再起動する必要があります。
  2. ディスク上のデータの破損を招いた外部イベント。これは、ディスク障害、ディスク容量不足、または必要なデータファイルの誤った変更などになります。この場合は、インスタンスをオフラインにし、oak-run チェックを使用して修復する必要があります。oak-run チェックの実行方法についての詳細は、以下の Apache ドキュメント を参照してください。
  3. 他のすべての状況では、アドビカスタマーケア に連絡して対処する必要があります。

エラーメッセージに基づくトラブルシューティング troubleshooting-based-on-error-messages

オンラインでのリビジョンクリーンアッププロセス中に問題が発生した場合、詳細な error.log が生成されます。以下のマトリックスでは、最も一般的なメッセージを説明し、解決策を示しています。

フェーズ
ログメッセージ
説明
次の手順
見積もり
TarMK GC #2:圧縮が一時停止されたので、見積もりはスキップされました
設定によってシステムでコンパクションが無効になっている場合は、見積もりフェーズがスキップされます。
オンラインでのリビジョンクリーンアップの有効化.
TarMK GC #2:見積もりが中断されました:${REASON}。Skipping compaction.
見積もりフェーズが完了せずに終了しました。見積もりフェーズを中断させる可能性があるイベントの例としては、ホストシステムでのメモリ不足やディスク領域の不足があります。
示されている理由によって異なります。
コンパクション
TarMK GC #2:コンパクションは一時停止されました
設定によってコンパクションフェーズが一時停止している限り、見積もりフェーズもコンパクションフェーズも実行されません。
オンラインでのリビジョンクリーンアップの有効化。
TarMK GC #2:コンパクションがキャンセルされました:${REASON}。
コンパクションフェーズが完了せずに終了しました。コンパクションフェーズを中断させる可能性があるイベントの例としては、ホストシステムでのメモリ不足やディスク領域の不足があります。さらに、システムをシャットダウンするか、操作ダッシュボード内のメンテナンスウィンドウなどの管理インターフェイスを使用して明示的にキャンセルした場合も、コンパクションがキャンセルされることがあります。
示されている理由によって異なります。
TarMK GC #2:5 回のサイクル後、32.902 分 (1974140 ms) でコンパクションに失敗しました
このメッセージは、復旧不可能なエラーがあったのではなく、一定数の試行の後にコンパクションが終了されたことのみを意味します。また、 次の段落 を参照してください。
以下の Oak ドキュメント および オンラインでのリビジョンクリーンアップの実行 の節の最後の質問をお読みください。
クリーンアップ
TarMK GC #2:クリーンアップが中断されました
リポジトリーをシャットダウンしてクリーンアップがキャンセルされました。整合性への影響はありません。また、ディスク容量が完全に再利用されない可能性が最も高くなります。 残りの領域は、次のリビジョンクリーンアップサイクルで再利用されます。
リポジトリがシャットダウンされた理由を調査し、今後はメンテナンスウィンドウ中にリポジトリがシャットダウンされないようにします。

オフラインでのリビジョンクリーンアップの実行方法 how-to-run-offline-revision-cleanup

CAUTION
AEMのインストールで使用する Oak バージョンに応じて、異なるバージョンの Oak-run ツールを使用する必要があります。 ツールを使用する前に、以下のバージョン要件のリストを確認してください。
  • Oak バージョン  1.0.0 ~ 1.0.11 ​または​ 1.1.0 ~ 1.1.6 ​の場合は、Oak-run バージョン​** 1.0.11** を使用します。

  • 上述のものよりも新しい Oak バージョンについては、AEM インストールの Oak コアと一致するバージョンの oak-run を使用します。

アドビは、リビジョンクリーンアップを実行するための  Oak-run  というツールを提供しています。このツールは以下のページでダウンロードできます。

https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/

このツールは、手動で実行してリポジトリをコンパクションできる実行可能な jar です。このプロセスは、ツールを正しく実行するためにリポジトリをシャットダウンする必要があるので、オフラインでのリビジョンクリーンアップと呼ばれます。メンテナンスウィンドウに従って、クリーンアップを計画してください。

クリーンアッププロセスのパフォーマンスを高める方法のヒントについては、オフラインでのリビジョンクリーンアップのパフォーマンスの向上を参照してください。

NOTE
メンテナンスを行う前に、古いチェックポイントを消去することもできます(以下の手順 2 と 3)。これは、100 を超えるチェックポイントを持つインスタンスに対してのみお勧めします。
  1. 常に AEM インスタンスの最新のバックアップがあることを確認してください。

    AEM をシャットダウンします。

  2. (オプション)ツールを使用して古いチェックポイントを検索します。

    code language-xml
    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
  3. (オプション)次に、未参照のチェックポイントを削除します。

    code language-xml
    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
  4. コンパクションを実行し、完了するまで待ちます。

    code language-xml
    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
    

オフラインでのリビジョンクリーンアップのパフォーマンスの向上 increasing-the-performance-of-offline-revision-cleanup

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 に設定します。oak-run ツールの​ バージョン 1.4  以上が必要です。詳しくは、オフラインでのリビジョンクリーンアップに関するよくある質問の節の質問 3 を参照してください。このパラメーターは Oak バージョン 1.6 で削除されており、効果はありません。

  • –force. ​コンパクションを強制的に実行し、一致しないセグメントストアバージョンは無視されます。

CAUTION
--force パラメーターを使用すると、セグメントストアが、古い Oak バージョンとは互換性のない最新バージョンにアップグレードされます。また、ダウングレードが不可能であることも考慮に入れます。原則としてこれらのパラメーターは、使い方に関する知識がある場合にのみ慎重に使用してください。

使用中のパラメーターの例を次に示します。

java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

リビジョンクリーンアップをトリガーするその他の方法 additional-methods-of-triggering-revision-cleanup

上記の方法に加えて、次のように JMX コンソールを使用して、リビジョンのクリーンアップメカニズムをトリガーすることもできます。

  1. http://localhost:4502/system/console/jmx にアクセスして JMX コンソールを開きます。
  2. RevisionGarbageCollection MBean をクリックします。
  3. 次のウィンドウで、startRevisionGC() をクリックし、起動 ​して、リビジョンのガベージコレクションジョブを開始します。

オフラインでのリビジョンクリーンアップに関するよくある質問 offline-revision-cleanup-frequently-asked-questions

オフラインでのリビジョンクリーンアップの時間に作用する要因は何ですか。
クリーンアップの実行時間は、リポジトリサイズとクリーンアップする必要があるリビジョンの数によって決まります。
リビジョンとページバージョンの違いは何ですか。
  • Oak リビジョン: Oak では、ノードとプロパティで構成される大規模なツリー階層ですべてのコンテンツを整理しています。このコンテンツツリーの各スナップショットまたはリビジョンは不変であり、ツリーの変更は新しいリビジョンのシーケンスとして表されます。通常、コンテンツを変更するたびに新しいリビジョンがトリガーされます。リンクをフォロー も参照してください。
  • ページバージョン: バージョン管理では、特定の時点でのページの「スナップショット」が作成されます。通常は、ページがアクティベートされたときに新しいバージョンが作成されます。詳細情報に関しては、ページバージョンの処理 を参照してください。
オフラインでのリビジョンクリーンアップのタスクが 8 時間以内に完了しない場合に、このタスクを高速化するにはどうすればよいですか。
リビジョンタスクが 8 時間以内に完了せず、スレッドダンプで主なホットスポットがInMemoryCompactionMap.findEntryであると示されている場合は、oak-run ツール バージョン 1.4 またはそれ以上で以下のパラメーターを使用します:-Dtar.PersistCompactionMap=true-Dtar.PersistCompactionMap パラメーターは Oak バージョン 1.6 で削除されたことにご注意ください。
recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56