リポジトリを更新するたびに、新しいコンテンツのリビジョンが作成されます。その結果、更新のたびにリポジトリのサイズが大きくなります。ディスクリソースを解放するには、古いリビジョンをクリーンアップする必要があります。これは、リポジトリが無制限に増加するのを防ぐために重要です。このメンテナンス機能は、リビジョンクリーンアップと呼ばれます。AEM 6.0 以降、オフラインルーチンとして使用可能になりました。
AEM 6.3 以降では、この機能のオンラインバージョンである「オンラインでのリビジョンクリーンアップ」が導入されました。オフラインのリビジョンクリーンアップでは AEM インスタンスをシャットダウンする必要があるのに対し、オンラインのリビジョンクリーンアップでは AEM インスタンスがオンラインの間に実行できます。オンラインのリビジョンクリーンアップはデフォルトでオンになっており、リビジョンのクリーンアップを実行する方法として推奨されます。
メモ:オンラインでのリビジョンクリーンアップの概要および使用方法について詳しくは、ビデオを参照してください。
リビジョンクリーンアップのプロセスは、見積もり、コンパクション、クリーンアップの 3 つのフェーズで構成されます。見積もりフェーズでは、収集されるガベージの量に基づいて、次のフェーズ(コンパクション)を実行するかどうかが判断されます。コンパクションフェーズでは、未使用のコンテンツを除いて、セグメントと tar ファイルが書き換えられます。その後のクリーンアップフェーズでは、ガベージも含めて、古いセグメントが削除されます。通常、オフラインモードではより多くの領域を再利用できます。これは、オンラインモードでは、追加のセグメントを収集しないようにする AEM の作業セットを考慮する必要があるからです。
リビジョンクリーンアップについて詳しくは、次のリンクを参照してください。
また、Oak の公式ドキュメント も参考になります。
リビジョンのクリーンアップを実行する場合は、オンラインでのリビジョンクリーンアップをお勧めします。 オフラインでのリビジョンクリーンアップは、例外的な場合にのみ使用してください。例えば、新しいストレージ形式に移行する前や、アドビカスタマーケアから依頼された場合です。
オンラインでのリビジョンクリーンアップは、AEM のオーサーインスタンスとパブリッシュインスタンスの両方で、1 日に 1 回自動的に実行されるようにデフォルトで設定されています。必要な操作は、ユーザーアクティビティが最も少ない時間帯に、メンテナンスウィンドウを定義することだけです。オンラインでのリビジョンクリーンアップタスクは、次のように設定します。
メイン AEM ウィンドウで、ツール/運営/ダッシュボード/メンテナンスに移動するか、ブラウザーで https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
を指定してください。
日別メンテナンスウィンドウにマウスポインターを置き、「設定」アイコンをクリックしてください。
必要な値(繰り返し、開始時刻、終了時刻)を入力し、「保存」をクリックします。
または、リビジョンクリーンアップのタスクを手動で実行する場合は、次の手順を実行します。
ツール/運営/ダッシュボード/メンテナンスに移動するか、https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
を直接参照してください。
日別メンテナンスウィンドウをクリックします。
リビジョンクリーンアップ のアイコンにマウスポインターを置きます。
「実行」をクリックします。
リビジョンクリーンアップのプロセスでは、古いリビジョンが世代ごとに再利用されます。つまり、リビジョンクリーンアップを実行するたびに、新しい世代が作成されてディスクに保持されます。ただし、リビジョンクリーンアップにはオフラインとオンラインの 2 種類があり、オフラインでのリビジョンクリーンアップは 1 つの世代を保持し、オンラインでのリビジョンクリーンアップは 2 つの世代を保持するという違いがあります。そのため、オフラインでのリビジョンクリーンアップを実行した後 にオンラインでのリビジョンクリーンアップを実行した場合は、以下のようになります。
また、コミットの種類と数に応じて、各世代のサイズが以前の世代と異なる場合があるため、最終的なサイズは実行によって異なる可能性があります。
そのため、当初予測していたたリポジトリサイズよりも、少なくとも 2 倍または 3 倍大きなディスクサイズにすることをお勧めします。
AEM 6.5 では、オンラインでのリビジョンクリーンアッププロセスのコンパクションフェーズ用に 2 つの新しいモードが導入されています。
これらのコンパクションモードでは、効率とリソース消費がトレードオフされます。テールコンパクションは効果が低いものの、通常のシステム運用に対する影響も少なくなります。一方、フルコンパクションはより効果的ですが、通常のシステム運用に大きな影響を与えます。
また、AEM 6.5 では、コンパクション時のより効率的なコンテンツの重複除外メカニズムが導入されました。これにより、リポジトリのディスク上のフットプリントがさらに削減されます。
次の 2 つの図は、AEM 6.3 と比較した AEM 6.5 の平均実行時間とディスク上の平均フットプリントの減少を示す社内ラボでのテスト結果を示しています。
デフォルト設定では、テールコンパクションを平日に、フルコンパクションを日曜日に実行します。デフォルト設定は、RevisionCleanupTask
メンテナンスタスク の新しい設定値 full.gc.days
を使用することで変更できます。
full.gc.days
値を設定する場合、フルコンパクションは値で定義された日に実行され、テールコンパクションは値で定義されていない日に実行されることにご注意ください。例えば、フルコンパクションを日曜日に実行するように設定した場合、テールコンパクションは月曜日から土曜日に実行されます。例えば、フルコンパクションを毎日実行するように設定した場合、テールコンパクションはまったく実行されません。
また、以下の点に留意してください。
新しいコンパクションモードを使用する場合は、次の点に注意してください。
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 にアップグレードするときの注意点を教えてください。 | TarMK の永続性形式が AEM 6.5 で変更されます。これらの変更には、事前の移行手順は必要ありません。既存のリポジトリは、周期的な移行を実行します。これはユーザーに対して透過的です。AEM 6.5(または関連ツール)がリポジトリに初めてアクセスすると、移行プロセスが開始されます。 AEM 6.5 永続性形式への移行が開始されると、リポジトリを以前の AEM 6.3 永続性形式に戻すことはできなくなります。 |
質問 | 回答 | |
リポジトリを移行する必要があるのはなぜですか。 | 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 への移行によって、コンテナ形式が変更されます。含まれているデータに影響はなく、データは変更されません。 | |
移行中および移行後に必要と予想されるディスク領域を計算する最適な方法を教えてください。 | この移行は、セグメントストアを新しい形式で再作成することに相当します。これは、移行中に必要な追加のディスク容量を見積もるために使用できます。古いセグメントストアは移行後に削除して、領域を再利用することができます。 | |
移行時間の最適な見積もり方法を教えてください。 | 移行前にオフラインでのリビジョンクリーンアップを実行すると、移行のパフォーマンスを大幅に高めることができます。アップグレードプロセスの前提条件として、オフラインでのリビジョンクリーンアップを実行することをすべての顧客にお勧めします。一般に移行時間は、オフラインでのリビジョンクリーンアップタスクが移行前に実行されていると仮定して、オフラインでのリビジョンクリーンアップ時間と同程度です。 |
質問 | 回答 | |
オンラインでのリビジョンクリーンアップは、どのくらいの頻度で実行する必要がありますか。 | 1 日に 1 回。これは、操作ダッシュボードのデフォルトの設定です。 | |
オンラインでのリビジョンクリーンアップのメンテナンスタスクを開始する時間を設定する方法を教えてください。 | オンラインでのリビジョンクリーンアップの実行方法 の節を参照してください。 | |
オンラインでのリビジョンクリーンアップには、超過するべきではない実行頻度の上限がありますか。 | オンラインでのリビジョンクリーンアップは、デフォルト設定のとおり、1 日に 1 回実行することをお勧めします。 |
|
オンラインでのリビジョンクリーンアップの実行頻度を決定する主な指標は何ですか。 | オンラインでのリビジョンクリーンアップはメンテナンスタスクとして設定され、毎日自動的に実行されるので、実行頻度を決定する必要はありません。 | |
オンラインでのリビジョンクリーンアップを初めて実行したときに、領域が再利用されないのはなぜですか。 | オンラインでのリビジョンクリーンアップでは、古いリビジョンが世代ごとに再利用されます。リビジョンのクリーンアップが実行されるたびに、新しい世代が生成されます。少なくとも 2 世代前のコンテンツのみが再利用されます。つまり、最初の実行時には再利用されるコンテンツが何もありません。 | |
オフラインでのリビジョンクリーンアップの実行後に初めてオンラインでのリビジョンクリーンアップを実行したときに、領域が再利用されないのはなぜですか。 | オフラインでのリビジョンクリーンアップでは、最新の 2 世代のオンラインでのリビジョンクリーンアップと比較して、最新以外のすべての世代が再利用されます。新しいリポジトリの場合、オンラインでのリビジョンクリーンアップでは、オフラインでのリビジョンクリーンアップ後に初めて実行されたとき、再利用できるほど古い世代がないので、スペースを再利用できません。 この章の「オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合」の節も参照してください。 |
|
オンラインでのリビジョンクリーンアップは、通常、オーサーとパブリッシュでは異なる時間帯に実行しますか。 | いつ実行すべきかは、営業時間と顧客のオンラインプレゼンスのトラフィックパターンによって異なります。クリーンアップの効果を最大限に高めるには、メンテナンスウィンドウを主要な実稼動時間外に設定する必要があります。AEM パブリッシュインスタンス(TarMK ファーム)が複数ある場合は、オンラインでのリビジョンクリーンアップのメンテナンスウィンドウが重ならないように調整する必要があります。 | |
オンラインでのリビジョンクリーンアップを実行するための前提条件はありますか。 | オンラインでのリビジョンクリーンアップは、AEM 6.3 以降のリリースでのみ使用できます。また、古いバージョンの AEM を使用している場合は、新しい Oak Segment Tar に移行する必要があります。 |
|
オンラインでのリビジョンクリーンアップの時間に作用する要因は何ですか。 | 要因は次のとおりです。
|
|
オンラインでのリビジョンクリーンアップの実行中も作成者は作業できますか。 | はい、オンラインでのリビジョンクリーンアップは、同時書き込みに対応しています。ただし、オンラインでのリビジョンクリーンアップは、同時書き込みトランザクションを行わなくても高速かつ効率的に動作します。オンラインでのリビジョンクリーンアップのメンテナンスタスクは、大量のトラフィックが発生しない比較的静かな時間にスケジュールすることをお勧めします。 | |
オンラインでのリビジョンクリーンアップを実行するときのディスク領域とヒープメモリの最小要件を教えてください。 | オンラインでのリビジョンクリーンアップ中、ディスク領域は継続的に監視されます。使用可能なディスク領域が臨界値を下回った場合、プロセスはキャンセルされます。臨界値とは、リポジトリのその時点でのディスクフットプリントの 25%であり、変更はできません。 最初に予測したリポジトリサイズよりも少なくとも 2 倍または 3 倍大きなディスクサイズにすることをお勧めします。 クリーンアッププロセス中、空きヒープ領域が継続的に監視されます。空きヒープ領域が臨界値を下回った場合、プロセスはキャンセルされます。臨界値は、org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD を使用して設定します。デフォルト値は 15% です。 最小コンパクションヒープサイズ設定の推奨事項は、AEM のメモリサイズ設定の推奨事項と切り離されていません。原則として、AEM インスタンスが、ユースケースとそこで予測されるペイロードに対応するのに十分なサイズの場合、クリーンアッププロセスは十分なメモリを取得します。 |
|
オンラインでのリビジョンクリーンアップの実行中、パフォーマンスにはどのような影響があると予想されますか。 | オンラインでのリビジョンクリーンアップは、通常のシステム操作と並行してリポジトリの読み取りと書き込みを行うバックグラウンドプロセスです。特に、リポジトリへの排他的なアクセスを短時間取得し、他のスレッドがリポジトリに書き込まないようにする必要があります。 | |
オンラインでのリビジョンクリーンアップの所要時間はどのくらいですか。 | アドビ内部で実行した最新のパフォーマンステストによると、所要時間は 2 時間以下です。 | |
オンラインでのリビジョンクリーンアップにそれよりも長い時間がかかる場合はどうすればよいですか。 |
|
|
設定したメンテナンスウィンドウ中にオンラインでのリビジョンクリーンアップが終わらない場合は、何が起きていますか。 | 他のメンテナンスタスクによって、その実行が遅延されないようにしてください。これは、同じメンテナンスウィンドウ内で、オンラインでのリビジョンクリーンアップよりも多くのメンテナンスタスクが実行された場合に発生する可能性があります。なお、メンテナンスタスクは順番に実行されます。順番は変更できません。 | |
リビジョンのガベージコレクションがスキップされるのはなぜですか。 | リビジョンクリーンアップでは見積もりフェーズで、クリーンアップするのに十分なガベージがあるかどうかを判断します。見積もりでは、最後のコンパクション後のリポジトリのサイズと現在のサイズが比較されます。サイズが設定された差分を超えると、クリーンアップが実行されます。サイズの差分は 1 GB に設定されています。これは、リポジトリーのサイズが前回のクリーンアップの実行から 1 GB 増加しなかった場合、新しいリビジョンのクリーンアップの反復がスキップされることを事実上意味します。 見積もりフェーズに関連するログエントリは以下のとおりです。
|
|
パフォーマンスへの影響が大きすぎる場合に、自動コンパクションを安全に中止できますか。 | はい。AEM 6.3 以降では、操作ダッシュボード内のメンテナンスタスクウィンドウまたは JMX から安全に停止できます。 | |
スケジュールされたクリーンアップタスクの実行中に AEM インスタンスがシャットダウンされた場合、プロセスは安全に中止されますか。またはコンパクションが終了するまでシャットダウンがブロックされますか。 | リビジョンクリーンアップが中断され、リポジトリは安全にシャットダウンされます。 | |
オンラインでのリビジョンクリーンアップ中にシステムがクラッシュした場合はどうなりますか。 | このような場合にデータが破損するリスクはありません。残ったガベージは、その後の実行でクリーンアップされます。 | |
オンラインでのリビジョンクリーンアップを実行しないと、どのような影響がありますか。 | 時間の経過に伴いパフォーマンスが低下します。 | |
どのリビジョンが収集されますか。 | デフォルトでは、オンラインでのリビジョンクリーンアップで収集されるのは 24 時間以上前のリビジョンのみです。 | |
リポジトリへの同時書き込みからの干渉が多すぎる場合はどうなりますか。 | 同時書き込みが可能なシステムでは、コンパクションサイクルの終了時に変更をコミットできるように、オンラインでのリビジョンクリーンアップで排他書き込みアクセスが必要になる場合があります。システムは forceCompact モードになります。詳細に関しては、oak のドキュメントを参照してください。強制コンパクションでは、同時書き込みの干渉を受けずに最終的に変更をコミットするために、排他的な書き込みロックが取得されます。応答時間に対する影響を制限するために、タイムアウト値を定義できます。この値はデフォルトで 1 分に設定されています。つまり、1 分以内に強制コンパクションが完了しない場合は同時コミットが優先され、コンパクションプロセスは中止されます。 強制コンパクションの実行時間は以下の要素によって変動します。
|
|
スタンバイインスタンスでは、オンラインでのリビジョンクリーンアップはどのように実行されますか。 |
コールドスタンバイセットアップでは、オンラインでのリビジョンクリーンアップの実行を設定する必要があるのは、プライマリインスタンスのみです。スタンバイインスタンスで、オンラインでのリビジョンクリーンアップを明示的にスケジュールする必要はありません。 スタンバイインスタンスでの対応する操作は自動クリーンアップです。これは、オンラインでのリビジョンクリーンアップのクリーンアップフェーズに相当します。自動クリーンアップは、プライマリインスタンスでオンラインリビジョンクリーンアップが実行された後、スタンバイインスタンスで実行されます。 見積もりフェーズとコンパクションフェーズは、スタンバイインスタンスでは実行されません。 |
|
オフラインでのリビジョンクリーンアップでは、オンラインでのリビジョンクリーンアップよりも多くのディスク領域を解放できますか。 | オフラインでのリビジョンクリーンアップでは、古いリビジョンを即座に削除できますが、オンラインでのリビジョンクリーンアップでは、アプリケーションスタックによって参照されている古いリビジョンを考慮する必要があります。 そのため、前者は後者よりも積極的にガベージを削除することができ、数回のガベージ収集サイクルで効果が表れます。 この章の「オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合」の節も参照してください。 |
|
メモリマップファイル操作に関する考慮事項はありますか。 |
|
|
オンラインでのリビジョンクリーンアップ中に監視する必要があるものは何ですか。 |
|
|
オンラインでのリビジョンクリーンアップが正常に完了したかどうかを確認する方法を教えてください。 | オンラインでのリビジョンクリーンアップが正常に完了したかどうかは、ログを確認して確認できます。 例:「 それに伴い、クリーンアップステップの正常終了を示すメッセージ「 |
|
最新のオンラインでのリビジョンクリーンアップの実行に関する統計はどこで確認できますか。 | ステータス、進行状況および統計は、JMX( 進行状況は、 MBean の参照を取得するには、 確認できるのは、システムを最後に起動した以降の統計情報のみであることにご注意ください。外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。詳細に関しては、 外部の監視ツールの例として、Nagios にヘルスチェックを接続するための AEM のドキュメントを参照してください。 |
|
関連するログエントリは何ですか? |
また、エラーメッセージに基づくトラブルシューティングの節を参照してください。 |
|
オンラインでのリビジョンクリーンアップが完了した後に、どのくらいのスペースが再利用されたかを確認する方法は? | クリーンアップサイクルの最後に、ログに「TarMK GC #3: cleanup completed 」メッセージが表示されます。これにはリポジトリのサイズと再利用されたガベージの量も含まれます。 |
|
オンラインでのリビジョンクリーンアップが完了した後に、リポジトリの整合性を確認する方法を教えてください。 | オンラインでのリビジョンクリーンアップの後は、リポジトリの整合性チェックは必要ありません。 ただし、クリーンアップ後にリポジトリのステータスを確認するには、次の操作を実行できます。
|
|
オンラインでのリビジョンクリーンアップが失敗したかどうかを検出する方法と、回復する手順を教えてください。 | 失敗条件は、「TarMK GC」で始まる WARN または ERROR ログメッセージで示されます。 また、エラーメッセージに基づくトラブルシューティングの節を参照してください。 | |
リビジョンクリーンアップのヘルスチェックではどのような情報が表示されますか。ステータスレベルの色分けとの対応も教えてください。 | リビジョンのクリーンアップヘルスチェックは、 操作ダッシュボードの一部です。 オンラインでのリビジョンクリーンアップメンテナンスタスクの最後の実行が正常に完了した場合、ステータスは緑になります。 オンラインでのリビジョンクリーンアップのメンテナンスタスクが 1 回キャンセルされた場合、ステータスはイエローになります。 オンラインでのリビジョンクリーンアップのメンテナンスタスクを 3 回連続でキャンセルした場合は、赤になります。この場合、手動の操作が必要であるか、オンラインでのリビジョンクリーンアップが再び失敗する可能性が高くなります。詳細情報に関しては、以下のトラブルシューティングの節を参照してください。 システムの再起動後に、ヘルスチェックステータスがリセットされることにもご注意ください。そのため、新しく再起動したインスタンスは、リビジョンクリーンアップのヘルスチェックが緑色のステータスで表示されます。外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。外部の監視ツールの例として、Nagios にヘルスチェックを接続するための AEM のドキュメントを参照してください。 |
|
スタンバイインスタンスで自動クリーンアップを監視する方法を教えてください。 |
ステータス、進行状況および統計は、 MBean の参照は、 確認できるのは、システムが最後に起動されて以降の統計情報のみであることにご注意ください。外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。また、 外部の監視ツールの例として、Nagios にヘルスチェックを接続するための AEM のドキュメントも参照してください。 ログファイルを使用して、自動クリーンアップのステータス、進行状況および統計情報を確認することもできます。 |
|
スタンバイインスタンスでの自動クリーンアップ中に監視する必要があるものは何ですか。 |
|
オンラインでのリビジョンクリーンアップを実行しない場合に起こり得る最悪の状況は何ですか。 | AEM インスタンスのディスク領域が不足し、実稼動が停止します。 | |
パブリッシュインスタンスでオンラインでのリビジョンクリーンアップを実行する場合、ユーザートラフィックが多いことは問題になりますか。 | ユーザートラフィックが多いと、コンパクションフェーズを正常に完了できるかどうかに影響します。 |
|
ヘルスチェックおよびログエントリによると、オンラインでのリビジョンクリーンアップは 3 回連続で正常に完了していません。オンラインでのリビジョンクリーンアップを正常に完了させるには、何が必要ですか。 | 問題を見つけて修正するには、次の手順を実行します。
|
|
ヘルスチェックアラートがオンになった場合、何をする必要がありますか。 | この前の項目を参照してください。 | |
スケジュールされたメンテナンスウィンドウ中にオンラインでのリビジョンクリーンアップが時間切れになった場合、どうなりますか。 | オンラインでのリビジョンクリーンアップはキャンセルされ、残りは削除されます。メンテナンスウィンドウが次回スケジュールされると、再び開始されます。 | |
SegmentNotFoundException インスタンスが error.log に記録される理由と復旧方法を教えてください。 |
|
オンラインでのリビジョンクリーンアッププロセス中に問題が発生した場合、詳細な 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 を超えるチェックポイントを持つインスタンスに対してのみお勧めします。
常に AEM インスタンスの最新のバックアップがあることを確認してください。
AEM をシャットダウンします。
(オプション)ツールを使用して古いチェックポイントを検索します。
java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
(オプション)次に、未参照のチェックポイントを削除します。
java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
コンパクションを実行し、完了するまで待ちます。
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 コンソールを使用して、リビジョンのクリーンアップメカニズムをトリガーすることもできます。
オフラインでのリビジョンクリーンアップの時間に作用する要因は何ですか。 | クリーンアップの実行時間は、リポジトリサイズとクリーンアップする必要があるリビジョンの数によって決まります。 |
リビジョンとページバージョンの違いは何ですか。 |
|
オフラインでのリビジョンクリーンアップのタスクが 8 時間以内に完了しない場合に、このタスクを高速化するにはどうすればよいですか。 | リビジョンタスクが 8 時間以内に完了せず、スレッドダンプで主なホットスポットがInMemoryCompactionMap.findEntry であると示されている場合は、oak-run ツールバージョン 1.4またはそれ以上で以下のパラメーターを使用します:-Dtar.PersistCompactionMap=true 。-Dtar.PersistCompactionMap パラメーターは Oak バージョン 1.6 で削除されたことにご注意ください。 |