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

最終更新日: 2023-11-07
  • トピック:
  • Configuring
    このトピックの詳細を表示
  • 作成対象:
  • Developer

はじめに

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

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

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

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

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

また、 公式 Oak ドキュメント.

オフラインでのリビジョンクリーンアップではなく、オンラインのリビジョンクリーンアップを使用する場合

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

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

オンラインでのリビジョンクリーンアップは、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

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

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

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

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

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

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

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

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

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

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

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

onrc-duration-6_4vs63 segmentstore-6_4vs63

フルコンパクションおよびテールコンパクションの設定方法

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

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

また、次の点にも注意してください。

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

トラブルシューティング

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

  • 入出力(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

既知の制限事項

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

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

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

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

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

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

AEM 6.5 永続化形式への移行が開始されると、リポジトリを以前のAEM 6.3 永続化形式に戻すことはできません。

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 モジュールを実行しようとすると(または逆に)、起動が失敗し、 IllegalStateException を「無効なセグメントフォーマット」というメッセージに置き換えます。 データの破損は発生しません。
検索インデックスの再作成は必要ですか。 いいえ。oak-segment から oak-segment-tar への移行によって、コンテナ形式が変更されます。含まれているデータに影響はなく、データは変更されません。
移行中および移行後に必要と予想されるディスク領域を計算する最適な方法を教えてください。 この移行は、セグメントストアを新しい形式で再作成することに相当します。これは、移行中に必要な追加のディスク容量を見積もるために使用できます。古いセグメントストアは移行後に削除して、領域を再利用することができます。
移行時間の最適な見積もり方法を教えてください。 移行前にオフラインでのリビジョンクリーンアップを実行すると、移行のパフォーマンスを大幅に高めることができます。アップグレードプロセスの前提条件として、オフラインでのリビジョンクリーンアップを実行することをすべての顧客にお勧めします。一般に移行時間は、オフラインでのリビジョンクリーンアップタスクが移行前に実行されていると仮定して、オフラインでのリビジョンクリーンアップ時間と同程度です。

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

質問 回答
オンラインでのリビジョンクリーンアップは、どのくらいの頻度で実行する必要がありますか。 1 日に 1 回。これは、操作ダッシュボードのデフォルトの設定です。
オンラインでのリビジョンクリーンアップのメンテナンスタスクを開始する時間を設定する方法を教えてください。 オンラインでのリビジョンクリーンアップの実行方法 の節を参照してください。
オンラインでのリビジョンクリーンアップには、超過するべきではない実行頻度の上限がありますか。 オンラインでのリビジョンクリーンアップは、デフォルト設定のとおり、1 日に 1 回実行することをお勧めします。
オンラインでのリビジョンクリーンアップの実行頻度を決定する主な指標は何ですか。 オンラインでのリビジョンクリーンアップはメンテナンスタスクとして設定され、毎日自動的に実行されるので、実行頻度を決定する必要はありません。
オンラインでのリビジョンクリーンアップを初めて実行したときに、領域が再利用されないのはなぜですか。 オンラインでのリビジョンクリーンアップでは、古いリビジョンが世代ごとに再利用されます。リビジョンのクリーンアップが実行されるたびに、新しい世代が生成されます。少なくとも 2 世代前のコンテンツのみが再利用されます。つまり、最初の実行時には再利用されるコンテンツが何もありません。
オフラインでのリビジョンクリーンアップの実行後に初めてオンラインでのリビジョンクリーンアップを実行したときに、領域が再利用されないのはなぜですか。

オフラインでのリビジョンクリーンアップでは、最新の 2 世代のオンラインでのリビジョンクリーンアップと比較して、最新以外のすべての世代が再利用されます。新しいリポジトリがある場合、オフラインでのリビジョンクリーンアップ後に初めて実行したときに、再利用できる古い世代がないので、オンラインでのリビジョンクリーンアップでは領域を再利用できません。

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

オンラインでのリビジョンクリーンアップは、通常、オーサーとパブリッシュでは異なる時間帯に実行しますか。 いつ実行すべきかは、営業時間と顧客のオンラインプレゼンスのトラフィックパターンによって異なります。クリーンアップの効果を最大限に高めるには、メンテナンスウィンドウを主要な実稼動時間外に設定する必要があります。AEM パブリッシュインスタンス(TarMK ファーム)が複数ある場合は、オンラインでのリビジョンクリーンアップのメンテナンスウィンドウが重ならないように調整する必要があります。
オンラインでのリビジョンクリーンアップを実行するための前提条件はありますか。

オンラインでのリビジョンクリーンアップは、AEM 6.3 以降のリリースでのみ使用できます。また、古いバージョンのAEMを使用している場合は、新しい Oak Segment Tar.

オンラインでのリビジョンクリーンアップの時間に作用する要因は何ですか。 要因は次のとおりです。
  • リポジトリのサイズ
  • システムへの負荷(リクエスト/分、特に書き込み操作)
  • アクティビティパターン(読み取りと書き込み)
  • ハードウェアの仕様(CPU パフォーマンス、メモリ、IOPS)
オンラインでのリビジョンクリーンアップの実行中も作成者は作業できますか。 はい、オンラインでのリビジョンクリーンアップは、同時書き込みに対応しています。ただし、オンラインでのリビジョンクリーンアップは、同時書き込みトランザクションを行わなくても高速かつ効率的に動作します。Adobeは、オンラインでのリビジョンクリーンアップのメンテナンスタスクを、大量のトラフィックが発生しない比較的静かな時間にスケジュールすることをお勧めします。
オンラインでのリビジョンクリーンアップを実行するときのディスク領域とヒープメモリの最小要件を教えてください。

オンラインでのリビジョンクリーンアップ中、ディスク領域は継続的に監視されます。使用可能なディスク領域が重大な値を下回った場合、プロセスはキャンセルされます。 臨界値とは、リポジトリのその時点でのディスクフットプリントの 25%であり、変更はできません。

Adobeでは、最初に推定されたリポジトリサイズの 2 倍または 3 倍以上のディスクサイズを使用することをお勧めします。

クリーンアッププロセス中、空きヒープ領域が継続的に監視されます。空きヒープ領域が重大な値を下回った場合、プロセスはキャンセルされます。 臨界値は、org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD を使用して設定します。デフォルト値は 15% です。

最小コンパクションヒープサイズ設定のレコメンデーションは、AEM のメモリサイズ設定のレコメンデーションと切り離されていません。一般に: AEMインスタンスのサイズが、使用例とそれに対して予想されるペイロードに対応できるほど大きい場合、クリーンアッププロセスは十分なメモリを取得します。

オンラインでのリビジョンクリーンアップの実行中、パフォーマンスにはどのような影響があると予想されますか。 オンラインでのリビジョンクリーンアップは、通常のシステム操作と並行してリポジトリの読み取りと書き込みを行うバックグラウンドプロセスです。特に、リポジトリへの排他的なアクセスを短時間取得し、他のスレッドがリポジトリに書き込まれないようにする必要が生じる場合があります。
オンラインでのリビジョンクリーンアップの所要時間はどのくらいですか。 内部で実行された最新のパフォーマンステストAdobeに従って、実行するのに 2 時間以内にする必要があります。
オンラインでのリビジョンクリーンアップにそれよりも長い時間がかかる場合はどうすればよいですか。
  • クリーンアップが毎日実行されていることを確認してください。
  • 操作ダッシュボードでメンテナンスウィンドウを適切に設定して、リポジトリのアクティビティが最も少ない時間帯にクリーンアップが実行されるようにしてください。
  • システムリソース(CPU、メモリ、I/O)を拡張してください。
設定したメンテナンスウィンドウ中にオンラインでのリビジョンクリーンアップが終わらない場合は、何が起きていますか。 他のメンテナンスタスクが実行を遅延させていないことを確認します。 これは、同じメンテナンスウィンドウ内で、オンラインでのリビジョンクリーンアップよりも多くのメンテナンスタスクが実行された場合に発生する可能性があります。メンテナンスタスクは、順番を設定せずに順番に実行されます。
リビジョンのガベージコレクションがスキップされるのはなぜですか。

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

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

  • リビジョン GC の実行: サイズデルタは N%または N/N (N/N バイト)なので、コンパクションが実行されています
  • リビジョン GC が実行します not 実行: サイズデルタは 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 以外の環境の場合を使用する場合は、物理メモリのサイズを増やして、リポジトリのメモリマッピングを改善します。

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

オンラインでのリビジョンクリーンアップ中に監視する必要があるものを教えてください。
  • オンラインでのリビジョンクリーンアップが有効な場合は、ディスクスペースを監視する必要があります。ディスク容量が不足している場合は、クリーンアップが実行されないか、先にクリーンアップが終了します。
  • オンラインでのリビジョンクリーンアップの完了時間をログで確認してください。これは 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。 次の Oak ドキュメントも参照してください。

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

統計は、最後のシステム起動以降にのみ表示されます。 外部監視ツールを使用すると、AEMの稼動時間を超えてデータを保持できます。 また、 外部の監視ツールの例として、Nagios にヘルスチェックを接続するための AEM のドキュメントも参照してください。

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

スタンバイインスタンスでの自動クリーンアップ中に監視する必要があるものを教えてください。

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

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

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

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

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

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

オンラインでのリビジョンクリーンアッププロセス中に問題が発生した場合、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:クリーンアップが中断されました。 リポジトリをシャットダウンしてクリーンアップがキャンセルされました。 整合性への影響はありません。また、多くの場合、ディスク容量は完全には再利用されません。残りの領域は、次のリビジョンクリーンアップサイクルで再利用されます。 リポジトリがシャットダウンされた理由を調査し、今後はメンテナンスウィンドウ中にリポジトリがシャットダウンされないようにします。

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

注意

AEMインストールの Oak コアバージョンと一致するバージョン番号(メジャーとマイナーの両方)を持つ Oak-run ツールリリースを使用します。 例えば、AEM インスタンスに Oak コアバージョン 1.22.x がある場合、Oak-run ツール 1.22.x の最新バージョンを使用する必要があります。

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

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

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

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

メモ

メンテナンスを行う前に、古いチェックポイントを消去することもできます(以下の手順 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 に設定します。 oak-run ツールの​バージョン 1.4 以上が必要です。詳しくは、オフラインでのリビジョンクリーンアップに関するよくある質問の節の質問 3 を参照してください。このパラメーターは Oak バージョン 1.6 で削除されており、効果はありません。

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

注意

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

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

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

このページ