現在表示中:

概要

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

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

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

リビジョンクリーンアップのプロセスは、見積もりコンパクションおよびクリーンアップの 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

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

Oak Segment Tar への移行

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

特に、オンラインでのリビジョンクリーンアップのパフォーマンスと効果を高めるために、ストレージ形式の変更が必要になったことがその理由です。この変更には後方互換性がないので、古い 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 増加していない場合、新しいリビジョンクリーンアップの反復がスキップされることを実質的に意味します。 

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

  • 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 時間以上前のリビジョンのみです。  
リポジトリへの同時書き込みからの干渉が多すぎる場合、どうなりますか。

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

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

  • ハードウェア(具体的には IOPS):IOPS が増えると実行時間が短縮されます。
  • セグメントストアサイズ:実行時間はセグメントストアのサイズに伴って増大します。
 

スタンバイインスタンスでは、オンラインでのリビジョンクリーンアップはどのように実行されますか。

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

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

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

 
オフラインでのリビジョンクリーンアップでは、オンラインでのリビジョンクリーンアップよりも多くのディスク領域を解放できますか。 オフラインでのリビジョンクリーンアップでは古いリビジョンをすぐに削除できますが、オンラインでのリビジョンクリーンアップでは、古いリビジョンが引き続きアプリケーションスタックによって参照されていることを考慮する必要があります。そのため、オフラインのほうがオンラインよりも積極的にガベージを削除できますが、ガベージコレクションサイクルを数回経ると、この効果は薄れます。  

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

オンラインでのリビジョンクリーンアップ中に監視する必要があるものは何ですか。
  • オンラインでのリビジョンクリーンアップが有効な場合、ディスク領域を監視する必要があります。ディスク領域が不十分な場合、クリーンアップは実行されないか、早期に終了します。
  • オンラインでのリビジョンクリーンアップの完了時間をログで確認してください。これは 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

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

バージョン 1.0.22 以降の oak-run ツールには、リビジョンクリーンアッププロセスのパフォーマンスを向上させ、メンテナンスウィンドウをできる限り最短化するための複数の機能が導入されています。

このような機能には、以下に示すコマンドラインパラメーターが含まれます。

  • -Dtar.memoryMapped。これは、tar ファイルに対するメモリマップ操作を有効にして、パフォーマンスを大幅に高めるために使用します。これは true または false に設定します。コンパクションを高速化するために、この機能を有効にすることを強くお勧めします。
  • -Dupdate.limit。一時トランザクションをディスクにフラッシュするためのしきい値を定義します。デフォルト値は 5000000 です。
  • -Dcompress-interval。現在のマップを圧縮するまで保持するコンパクションマップエントリの数です。デフォルトは 1000000 です。十分なヒープメモリが使用可能な場合は、スループットを高速化するために、この値をさらに大きい数に増やします。
  • -Dcompaction-progress-log。ログに記録される、コンパクションされたノードの数です。デフォルト値は 1500000 です。これは、最初の 1,500,000 個のコンパクションされたノードが操作中にログに記録されることを意味します。このパラメーターは、次に示すパラメーターとともに使用します。
  • -Dtar.PersistCompactionMap。コンパクションマップを保持するためにヒープメモリの代わりにディスク領域を使用するには、このパラメーターを true に設定します。oak-run ツールのバージョン 1.4 以上が必要です。詳しくは、オフラインでのリビジョンクリーンアップに関するよくある質問の節の質問 3 を参照してください。

警告:

一部のバージョンの Windows では、メモリマップファイル操作が正しく動作しません。Windows プラットフォームでは、必ず -Dtar.memoryMapped パラメーターを指定せずにツールを使用してください。そうしない場合、リビジョンクリーンアップは失敗します。

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

java -Dtar.memoryMapped=true -Dupdate.limit=5000000 -Dcompress-interval=10000000 -Dcompaction-progress-log=1500000 -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 パラメーターを使用します。 

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

法律上の注意   |   プライバシーポリシー