リポジトリが更新されるたびに、新しいコンテンツのリビジョンが作成されます。その結果、更新のたびにリポジトリのサイズが大きくなります。 リポジトリのサイズが無制限に増大しないように、古いリビジョンをクリーンアップして、ディスクリソースを解放する必要があります。このメンテナンス機能は、リビジョンクリーンアップと呼ばれます。AEM 6.0 以降では、この機能をオフラインルーチンとして使用できます。
AEM 6.3 では、この機能のオンラインバージョンである「オンラインでのリビジョンクリーンアップ」が導入されました。AEM インスタンスをシャットダウンする必要があったオフラインのリビジョンクリーンアップとは異なり、オンラインでのリビジョンクリーンアップは AEM インスタンスがオンラインの状態で実行できます。オンラインでのリビジョンクリーンアップはデフォルトで有効になります。リビジョンクリーンアップを実行する際はこの方法を使用することが推奨されます。
注意: オンラインリビジョンクリーンアップの概要と使用方法については、 ビデオを参照してください。
リビジョンクリーンアップのプロセスは、見積もり、コンパクションおよびクリーンアップの 3 つのフェーズで構成されます。見積もりでは、収集される可能性があるガベージの量に基づいて、次のフェーズ(コンパクション)を実行するかどうかが判別されます。コンパクションフェーズでは、セグメントおよび tar ファイルが未使用のコンテンツを除いて再作成されます。次のクリーンアップフェーズでは、含まれているガベージを含め、古いセグメントが削除されます。通常、オフラインモードのほうが多くの領域を再利用できます。これは、オンラインモードでは AEM の作業セットを保持する必要があり、収集されないセグメントがあるためです。
リビジョンクリーンアップについて詳しくは、以下のリンクを参照してください。
推奨されているリビジョンクリーンアップの実行方法は、オンラインでのリビジョンクリーンアップです。 オフラインリビジョンのクリーンアップは、例外的なベースでのみ使用してください。例えば、新しいストレージ形式に移行する前に、またはAdobeカスタマーケアから要求があった場合に使用します。
オンラインでのリビジョンクリーンアップは、デフォルトで、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 つの新しいモードが導入されています。
この 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 倍または 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 にアップグレードしてから、(例えば、別のメンテナンスウィンドウを使用して)後で移行を実行できますか。 | できません。前述のとおり、コンテンツの移行は必須です。 | |
移行時のダウンタイムは回避できますか。 | いいえ。これは一度におこなう作業であり、実行中のインスタンスでは実行できません。 | |
誤って不適切なリポジトリ形式に対して移行を実行した場合はどうなりますか。 | oak-segment-tarリポジトリに対してoak-segmentモジュールを実行しようとすると(またはその逆)、起動が失敗し、IllegalStateExceptionが表示され、「Invalid segment format」というメッセージが表示されます。 データが破損することはありません。 | |
検索インデックスの再作成は必要ですか。 | いいえ。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 時間以上前のリビジョンのみです。 | |
同時書き込みからリポジトリへの干渉が多すぎる場合、どうなりますか。 | 同時書き込みが可能なシステムでは、コンパクションサイクルの終了時に変更をコミットできるように、オンラインでのリビジョンクリーンアップで排他書き込みアクセスが必要になる場合があります。oakドキュメントで詳しく説明されているように、システムはforceCompactモードに移行します。 強制コンパクション中は、同時書き込みによる干渉を受けることなく最終的に変更をコミットするために、排他書き込みロックが取得されます。応答時間に対する影響を制限するために、タイムアウト値を定義できます。デフォルトでは、この値は 1 分に設定されています。これは、1 分以内に強制コンパクションが完了しない場合、同時コミットが優先されてコンパクションプロセスが中止されることを意味します。 力のコンパクト化の時間は、次の要因によって異なります。
|
|
スタンバイインスタンスでは、オンラインでのリビジョンクリーンアップはどのように実行されますか。 |
コールドスタンバイセットアップでは、オンラインでのリビジョンクリーンアップの実行を設定する必要があるのは、プライマリインスタンスのみです。スタンバイ・インスタンスでは、オンライン・リビジョン・クリーンアップを特別にスケジュールする必要はありません。 スタンバイインスタンスでの対応する操作は、自動クリーンアップです。これは、オンラインリビジョンクリーンアップのクリーンアップフェーズに対応します。 プライマリインスタンスでオンラインでのリビジョンクリーンアップが実行された後に、スタンバイインスタンスで自動クリーンアップが実行されます。 見積もりフェーズとコンパクションフェーズはスタンバイインスタンスでは実行されません。 |
|
オフラインでのリビジョンクリーンアップでは、オンラインでのリビジョンクリーンアップよりも多くのディスク領域を解放できますか。 | オフラインでのリビジョンクリーンアップでは古いリビジョンをすぐに削除できますが、オンラインでのリビジョンクリーンアップでは、古いリビジョンが引き続きアプリケーションスタックによって参照されていることを考慮する必要があります。そのため、オフラインのほうがオンラインよりも積極的にガベージを削除できますが、ガベージコレクションサイクルを数回経ると、この効果は薄れます。 この章の「オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合」の節も参照してください。 |
|
メモリマップファイル操作に関する考慮事項はありますか。 |
|
|
オンラインリビジョンのクリーンアップ中に監視する必要のあるもの |
|
|
オンラインリビジョンのクリーンアップが正常に完了したかどうかを確認する方法 | オンラインリビジョンのクリーンアップが正常に完了したかどうかを確認するには、ログを確認します。 例えば、「 それに対応して、クリーンアップ手順が正常に完了したことを示すメッセージ「 |
|
最後のオンラインリビジョンのクリーンアップ実行の統計はどこで見つけることができますか? | ステータス、進行状況、および統計は、JMX( 進行状況は、 MBeanの参照は、 統計は、最後のシステム開始以降にのみ利用できます。 外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。外部監視ツールの例として、Nagiosにヘルスチェックを添付するAEMのドキュメントを参照してください。 |
|
関連するログエントリとは何ですか。 |
また、下のエラーメッセージに基づくトラブルシューティングの節も参照してください。 |
|
オンラインリビジョンのクリーンアップが完了した後に再利用された領域の量を確認する方法 | クリーンアップサイクルの最後に、ログに次のメッセージが表示されます。"TarMK GC #3: cleanup completed "。リポジトリのサイズと再生ごみの量を含みます。 |
|
オンラインリビジョンのクリーンアップが完了した後、リポジトリの整合性を確認する方法を教えてください。 | オンラインリビジョンのクリーンアップの後は、リポジトリの整合性チェックは必要ありません。 ただし、次の操作を実行して、クリーンアップ後にリポジトリのステータスを確認できます。
|
|
オンラインリビジョンのクリーンアップが失敗したかどうかを検出する方法と回復手順を教えてください。 | 失敗条件は、「TarMK GC」で始まるWARNまたはERRORログメッセージで示されます。 また、下のエラーメッセージに基づくトラブルシューティングの節も参照してください。 | |
リビジョンクリーンアップのヘルスチェックで公開される情報 ステータスレベルの色分けとの対応も教えてください。 | Revision Clean-up Health Checkは、Operationsダッシュボードの一部です。 オンラインリビジョンのクリーンアップメンテナンスタスクの最後の実行が正常に完了した場合、ステータスはGREENになります。 オンラインリビジョンのクリーンアップメンテナンスタスクが1回キャンセルされた場合は、YELLOWになります。 オンラインリビジョンのクリーンアップメンテナンスタスクが3回連続でキャンセルされた場合は、REDになります。 この場合、手動での操作が 必要です。また、オンラインリビジョンのクリーンアップが再び失敗する可能性があります。詳しくは、下のトラブルシューティングの節を参照してください。 また、システムを再起動した後にヘルスチェックのステータスがリセットされることにも注意してください。 そのため、新たに再起動されたインスタンスでは、リビジョンクリーンアップヘルスチェックで緑色のステータスが示されます。外部の監視ツールを利用すると、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 ツールを使用する必要があります。ツールを使用する前に、以下のバージョン要件を確認してください。
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 個を超えるインスタンスにのみ推奨されます。
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 tool バージョン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ツールversions 1.4 以降で次のパラメータを使用します。-Dtar.PersistCompactionMap=true 。 -Dtar.PersistCompactionMap パラメーターはOakバージョン1.6で削除されたことに注意してください。 |