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

はじめに

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

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

注意: オンラインでのリビ ジョンクリーンアップの概要と使用方法については、ビデオを参照してください。

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

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

さらに、公式のOakドキュメントも読むことができます。

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

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

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

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

  1. メインのAEMウィンドウで、Tools - Operations - Dashboard - Maintenance​に移動するか、ブラウザーで次の操作を行います。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 ファイルとは、フルコンパクションまたはテールコンパクションの前回の実行以降に追加されたセグメントと tar ファイルのことです。したがって、後続のクリーンアップフェーズでは、リポジトリの新しい部分に含まれるガベージのみを削除できます。テールコンパクションはリポジトリの一部にのみ影響するので、フルコンパクションよりも完了するのに必要なシステムリソースと時間が大幅に削減されます。

この 2 つのコンパクションモードでは、効果とリソース消費がトレードオフの関係にあります。テールコンパクションは効果は低くなりますが、システムの通常運用に与える影響も少なくなります。これに対し、フルコンパクションは効果は高くなりますが、システムの通常運用に大きな影響を与えます。

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

既知の制限事項

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

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

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

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

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

TarMK の永続性形式が AEM 6.5 で変更されます。これらの変更には、事前の移行手順は必要ありません。既存のリポジトリは、周期的な移行を実行します。これはユーザーに対して透過的です。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 にアップグレードしてから、(例えば、別のメンテナンスウィンドウを使用して)後で移行を実行できますか。 できません。前述のとおり、コンテンツの移行は必須です。
移行時のダウンタイムは回避できますか。 いいえ。これは一度におこなう作業であり、実行中のインスタンスでは実行できません。
誤って不適切なリポジトリ形式に対して移行を実行した場合はどうなりますか。 oak-segment-tarリポジトリに対してoak-segmentモジュールを実行しようとすると(またはその逆)、起動が失敗し、「Invalid segment format」というメッセージが表示されてIllegalStateExceptionが発生します。 データが破損することはありません。
検索インデックスの再作成は必要ですか。 いいえ。oak-segmentからoak-segment-tarへの移行では、コンテナ形式に変更が加えられます。 含まれているデータに影響はなく、データは変更されません。
移行中および移行後に必要と予想されるディスク領域を計算する最適な方法を教えてください。 移行とは、セグメントストアを新しい形式で作成し直すことと同義です。これを利用して、移行中に必要な追加のディスク領域を推定できます。移行後は、領域を再利用するために古いセグメントストアを削除できます。
移行時間の最適な見積もり方法を教えてください。 移行前にオフラインでのリビジョンクリーンアップを実行すると、移行のパフォーマンスを大幅に向上できます。 アップグレードプロセスの前提条件として、オフラインでのリビジョンクリーンアップを実行することをすべての顧客にお勧めします。一般に、移行の期間は、オフラインでのリビジョンクリーンアップタスクの期間と同じにする必要があります(移行前にオフラインでのリビジョンクリーンアップタスクが実行されている場合)。

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

質問 回答
オンラインでのリビジョンクリーンアップは、どのくらいの頻度で実行する必要がありますか。 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 時間以上前のリビジョンのみです。
リポジトリへの同時書き込みからの干渉が多すぎる場合はどうなりますか。

同時書き込みが可能なシステムでは、コンパクションサイクルの終了時に変更をコミットできるように、オンラインでのリビジョンクリーンアップで排他書き込みアクセスが必要になる場合があります。oakのドキュメントで詳しく説明されているように、システムはforceCompactモードに移行します。 強制コンパクション中は、同時書き込みによる干渉を受けることなく最終的に変更をコミットするために、排他書き込みロックが取得されます。応答時間に対する影響を制限するために、タイムアウト値を定義できます。デフォルトでは、この値は 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)を介して公開されます。 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ログメッセージで示されます。 以下のエラーメッセージに基づくトラブルシューティングの節も参照してください。
リビジョンクリーンアップヘルスチェックで公開される情報は何ですか。 ステータスレベルの色分けとの対応も教えてください。

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

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

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

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

また、システムを再起動した後にヘルスチェックのステータスがリセットされることに注意してください。 そのため、新たに再起動されたインスタンスでは、リビジョンクリーンアップヘルスチェックで緑色のステータスが示されます。外部の監視ツールを利用すると、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時間を超えないようにします。
  • 自動クリーンアップの実行後のセグメントストアのサイズ。 スタンバイインスタンスでのセグメントストアのサイズは、プライマリインスタンスでのサイズとほぼ同じである必要があります。

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

オンラインでのリビジョンクリーンアップを実行しない場合に起こり得る最悪の状況は何ですか。 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. その他すべての問題は、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 ツールを使用する必要があります。ツールを使用する前に、以下のバージョン要件を確認してください。

  • Oakバージョン​1.0.0 ~ 1.0.11​または​1.1.0 ~ 1.1.6​の場合は、Oak-runバージョン 1.0.11​を使用します。

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

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. Oakバージョン1.6では-Dtar.PersistCompactionMapパラメーターが削除されていることに注意してください。

このページ