リポジトリを更新するたびに、コンテンツのリビジョンが作成されます。その結果、更新のたびにリポジトリのサイズが大きくなります。古いリビジョンは、ディスクリソースを解放するためにクリーンアップする必要があります。これは、制御されないリポジトリの増加を防ぐために重要です。 このメンテナンス機能は、リビジョンクリーンアップと呼ばれます。Adobe Experience Manager(AEM)6.0 以降、オフラインルーチンとして使用できます。
AEM 6.3 以降では、この機能のオンラインバージョンである「オンラインでのリビジョンクリーンアップ」が導入されました。オフラインのリビジョンクリーンアップでは AEM インスタンスをシャットダウンする必要があるのに対し、オンラインのリビジョンクリーンアップでは AEM インスタンスがオンラインの間に実行できます。オンラインのリビジョンクリーンアップはデフォルトでオンになっており、リビジョンのクリーンアップを実行する方法として推奨されます。
メモ:オンラインでのリビジョンクリーンアップの概要および使用方法について詳しくは、ビデオを参照してください。
リビジョンのクリーンアッププロセスは、次の 3 つのフェーズで構成されます。 推定, 圧縮、および 片付ける. 見積もりフェーズでは、収集されるガベージの量に基づいて、次のフェーズ(コンパクション)を実行するかどうかが判断されます。コンパクションフェーズでは、未使用のコンテンツを除いて、セグメントと tar ファイルが書き換えられます。次に、クリーンアップフェーズでは、古いセグメントが削除され、古いセグメントに含まれる可能性のあるガベージも削除されます。 通常、オフラインモードではより多くの領域を再利用できます。これは、追加のセグメントを収集しないAEMの作業セットをオンラインモードで考慮する必要があるからです。
リビジョンクリーンアップについて詳しくは、次のリンクを参照してください。
また、 公式 Oak ドキュメント.
リビジョンのクリーンアップを実行する場合は、オンラインでのリビジョンクリーンアップをお勧めします。 オフラインでのリビジョンクリーンアップは、例外的な方法でのみ使用する必要があります。例えば、新しいストレージ形式に移行する前や、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 つの新しいモードが導入されています。
これらのコンパクションモードでは、効率とリソース消費がトレードオフされます。テールコンパクションは効果が低いものの、通常のシステム運用に対する影響も少なくなります。一方、フルコンパクションはより効果的ですが、通常のシステム運用に大きな影響を与えます。
また、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 にアップグレードするときの注意点を教えてください。 | AEM 6.5 での TarMK の永続性形式の変更。これらの変更には、事前に移行する手順は必要ありません。 既存のリポジトリは、ユーザーに対して透過的なローリング移行をおこないます。 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 モジュールを実行しようとすると(または逆に)、起動が失敗し、 IllegalStateException を「無効なセグメントフォーマット」というメッセージに置き換えます。 データの破損は発生しません。 | |
検索インデックスの再作成は必要ですか。 | いいえ。oak-segment から oak-segment-tar への移行によって、コンテナ形式が変更されます。含まれているデータに影響はなく、データは変更されません。 | |
移行中および移行後に必要と予想されるディスク領域を計算する最適な方法を教えてください。 | この移行は、セグメントストアを新しい形式で再作成することに相当します。これは、移行中に必要な追加のディスク容量を見積もるために使用できます。古いセグメントストアは移行後に削除して、領域を再利用することができます。 | |
移行時間の最適な見積もり方法を教えてください。 | 移行前にオフラインでのリビジョンクリーンアップを実行すると、移行のパフォーマンスを大幅に高めることができます。アップグレードプロセスの前提条件として、オフラインでのリビジョンクリーンアップを実行することをすべての顧客にお勧めします。一般に移行時間は、オフラインでのリビジョンクリーンアップタスクが移行前に実行されていると仮定して、オフラインでのリビジョンクリーンアップ時間と同程度です。 |
質問 | 回答 | |
オンラインでのリビジョンクリーンアップは、どのくらいの頻度で実行する必要がありますか。 | 1 日に 1 回。これは、操作ダッシュボードのデフォルトの設定です。 | |
オンラインでのリビジョンクリーンアップのメンテナンスタスクを開始する時間を設定する方法を教えてください。 | オンラインでのリビジョンクリーンアップの実行方法 の節を参照してください。 | |
オンラインでのリビジョンクリーンアップには、超過するべきではない実行頻度の上限がありますか。 | オンラインでのリビジョンクリーンアップは、デフォルト設定のとおり、1 日に 1 回実行することをお勧めします。 |
|
オンラインでのリビジョンクリーンアップの実行頻度を決定する主な指標は何ですか。 | オンラインでのリビジョンクリーンアップはメンテナンスタスクとして設定され、毎日自動的に実行されるので、実行頻度を決定する必要はありません。 | |
オンラインでのリビジョンクリーンアップを初めて実行したときに、領域が再利用されないのはなぜですか。 | オンラインでのリビジョンクリーンアップでは、古いリビジョンが世代ごとに再利用されます。リビジョンのクリーンアップが実行されるたびに、新しい世代が生成されます。少なくとも 2 世代前のコンテンツのみが再利用されます。つまり、最初の実行時には再利用されるコンテンツが何もありません。 | |
オフラインでのリビジョンクリーンアップの実行後に初めてオンラインでのリビジョンクリーンアップを実行したときに、領域が再利用されないのはなぜですか。 | オフラインでのリビジョンクリーンアップでは、最新の 2 世代のオンラインでのリビジョンクリーンアップと比較して、最新以外のすべての世代が再利用されます。新しいリポジトリがある場合、オフラインでのリビジョンクリーンアップ後に初めて実行したときに、再利用できる古い世代がないので、オンラインでのリビジョンクリーンアップでは領域を再利用できません。 また、の「オフラインでのリビジョンクリーンアップの後にオンラインでのリビジョンクリーンアップを実行する」の節も参照してください。 本章. |
|
オンラインでのリビジョンクリーンアップは、通常、オーサーとパブリッシュでは異なる時間帯に実行しますか。 | いつ実行すべきかは、営業時間と顧客のオンラインプレゼンスのトラフィックパターンによって異なります。クリーンアップの効果を最大限に高めるには、メンテナンスウィンドウを主要な実稼動時間外に設定する必要があります。AEM パブリッシュインスタンス(TarMK ファーム)が複数ある場合は、オンラインでのリビジョンクリーンアップのメンテナンスウィンドウが重ならないように調整する必要があります。 | |
オンラインでのリビジョンクリーンアップを実行するための前提条件はありますか。 | オンラインでのリビジョンクリーンアップは、AEM 6.3 以降のリリースでのみ使用できます。また、古いバージョンのAEMを使用している場合は、新しい Oak Segment Tar. |
|
オンラインでのリビジョンクリーンアップの時間に作用する要因は何ですか。 | 要因は次のとおりです。
|
|
オンラインでのリビジョンクリーンアップの実行中も作成者は作業できますか。 | はい、オンラインでのリビジョンクリーンアップは、同時書き込みに対応しています。ただし、オンラインでのリビジョンクリーンアップは、同時書き込みトランザクションを行わなくても高速かつ効率的に動作します。Adobeは、オンラインでのリビジョンクリーンアップのメンテナンスタスクを、大量のトラフィックが発生しない比較的静かな時間にスケジュールすることをお勧めします。 | |
オンラインでのリビジョンクリーンアップを実行するときのディスク領域とヒープメモリの最小要件を教えてください。 | オンラインでのリビジョンクリーンアップ中、ディスク領域は継続的に監視されます。使用可能なディスク領域が重大な値を下回った場合、プロセスはキャンセルされます。 臨界値とは、リポジトリのその時点でのディスクフットプリントの 25%であり、変更はできません。 Adobeでは、最初に推定されたリポジトリサイズの 2 倍または 3 倍以上のディスクサイズを使用することをお勧めします。 クリーンアッププロセス中、空きヒープ領域が継続的に監視されます。空きヒープ領域が重大な値を下回った場合、プロセスはキャンセルされます。 臨界値は、org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD を使用して設定します。デフォルト値は 15% です。 最小コンパクションヒープサイズ設定のレコメンデーションは、AEM のメモリサイズ設定のレコメンデーションと切り離されていません。一般に: AEMインスタンスのサイズが、使用例とそれに対して予想されるペイロードに対応できるほど大きい場合、クリーンアッププロセスは十分なメモリを取得します。 |
|
オンラインでのリビジョンクリーンアップの実行中、パフォーマンスにはどのような影響があると予想されますか。 | オンラインでのリビジョンクリーンアップは、通常のシステム操作と並行してリポジトリの読み取りと書き込みを行うバックグラウンドプロセスです。特に、リポジトリへの排他的なアクセスを短時間取得し、他のスレッドがリポジトリに書き込まれないようにする必要が生じる場合があります。 | |
オンラインでのリビジョンクリーンアップの所要時間はどのくらいですか。 | 内部で実行された最新のパフォーマンステストAdobeに従って、実行するのに 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 に記録される理由と復旧方法を教えてください。 |
A
|
オンラインでのリビジョンクリーンアッププロセス中に問題が発生した場合、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 。The -Dtar.PersistCompactionMap Oak バージョン 1.6 では、パラメーターが削除されました。 |