現在表示中:

概要

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

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

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

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

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

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

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

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

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

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

  1. AEM メインウィンドウで、ツール/運営/ダッシュボード/メンテナンスに移動するか、ブラウザーで http://serveraddress:serverport/libs/granite/operations/content/maintenance.html にアクセスします。

    chlimage_1
  2. 日別メンテナンスウィンドウ」にマウスポインターを置くか、「設定」アイコンをクリックします。

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

    chlimage_1

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

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

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

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

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

    chlimage_1

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

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

  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 の平均実行時間とディスク上の平均フットプリントの減少を示す社内ラボでのテスト結果を示しています。

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.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 にアップグレードしてから、(例えば、別のメンテナンスウィンドウを使用して)後で移行を実行できますか。 できません。前述のとおり、コンテンツの移行は必須です。  
移行時のダウンタイムは回避できますか。 いいえ。これは一度におこなう作業であり、実行中のインスタンスでは実行できません。  
誤って不適切なリポジトリ形式に対して移行を実行した場合はどうなりますか。 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 が実行される:Size delta is N% or N/N (N/N bytes), so running compaction
  • リビジョンの GC が実行されないSize delta is N% or N/N (N/N bytes), so skipping compaction for now
 
パフォーマンスへの影響が大きすぎる場合に、自動コンパクションを安全に中止できますか。 はい。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 時間以下である必要があります。
  • チェックポイントの数。コンパクションの実行時にチェックポイントが 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 について詳しくは、以下の段落を参照してください。

進行状況は、SegmentRevisionGarbageCollection MBeanEstimatedRevisionGCCompletion 属性を使用して追跡できます。

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

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

 
関連するログエントリはどれですか。
  • オンラインでのリビジョンクリーンアップの開始/停止
    • オンラインでのリビジョンクリーンアップは、見積もり、コンパクションおよびクリーンアップの 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」というメッセージがあり、ここにリポジトリのサイズと再利用されたガベージの量が示されています。  
オンラインでのリビジョンクリーンアップの完了後にリポジトリの整合性を確認するには、どうすればよいですか。

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

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

  • リポジトリトラバーサルチェック
  • 不整合がないかを確認するために、クリーンアッププロセスの完了後に oak-run ツールを使用します。確認方法について詳しくは、Apache ドキュメントを参照してください。このツールを実行するために AEM をシャットダウンする必要はありません。
 
オンラインでのリビジョンクリーンアップが失敗した場合はどのように検出し、どのような手順で復旧すればよいですか。 エラーの状況は、「TarMK GC」で始まる WARN または ERROR ログメッセージによって示されます。以下のエラーメッセージに基づくトラブルシューティングの節も参照してください。  
リビジョンクリーンアップのヘルスチェックではどのような情報が示されますか。ステータスレベルの色分けとの対応も教えてください。 

リビジョンクリーンアップのヘルスチェックは、操作ダッシュボードに含まれています。

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

オンラインでのリビジョンクリーンアップのメンテナンスタスクが 1 回キャンセルされている場合、ステータスは黄色です。

オンラインでのリビジョンクリーンアップのメンテナンスタスクが 3 回続けてキャンセルされている場合、ステータスは赤色です。この場合、手動での対応が必要です。対応しないと、多くの場合、オンラインでのリビジョンクリーンアップは再度失敗します。詳細は、下記のトラブルシューティングセクションをご覧ください。

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

 

スタンバイインスタンスでの自動クリーンアップを監視するには、どうすればよいですか。

ステータス、進行状況および統計情報は、SegmentRevisionGarbageCollection MBean を使用することによって JMX により示されます。以下の Oak ドキュメントも参照してください。 

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

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

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

 

スタンバイインスタンスでの自動クリーンアップ中に監視する必要があるものは何ですか。

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

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

オンラインでのリビジョンクリーンアップを実行しない場合に起こり得る最悪の状況は何ですか。 AEM インスタンスのディスク領域が不足し、実稼動が停止します。  
パブリッシュインスタンスでオンラインでのリビジョンクリーンアップを実行する場合、ユーザートラフィックが多いことは問題になりますか。 ユーザートラフィックが多いと、コンパクションフェーズを正常に完了できるかどうかに影響します。
 
ヘルスチェックおよびログエントリによると、オンラインでのリビジョンクリーンアップは 3 回連続で正常に完了していません。オンラインでのリビジョンクリーンアップを正常に完了させるには、何が必要ですか。 問題を検出して修正するには、以下の手順を実行します。
  • まず、ログエントリを確認します。
  • ログの情報に基づいて、適切な操作を実行します。
    • ログに、5 回の失敗したコンパクションサイクルと forceCompact サイクルでのタイムアウトが示されている場合は、リポジトリへの書き込みが少ない、処理が少ない時間帯にメンテナンスウィンドウをスケジュールします。リポジトリへの書き込みは、http://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. 他のすべての状況では、アドビカスタマーケアに連絡して対処する必要があります。
 

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

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

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

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

警告:

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 Core に一致するバージョンの Oak-run を使用します。

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

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

リーガルノーティス   |   プライバシーポリシー