AEM 6.5 での TarMK の永続性形式の変更。これらの変更には、事前に移行する手順は必要ありません。 既存のリポジトリは、ユーザーに対して透過的なローリング移行をおこないます。 AEM 6.5（または関連ツール）がリポジトリに初めてアクセスすると、移行プロセスが開始されます。

AEM 6.5 永続化形式への移行が開始されると、リポジトリを以前のAEM 6.3 永続化形式に戻すことはできません。

AEM 6.3 で、特にオンラインでのリビジョンクリーンアップのパフォーマンスと効果を高めるために、ストレージ形式の変更が必要となりました。これらの変更は後方互換性がなく、古い Oak セグメント（AEM 6.2 以前）で作成されたリポジトリは移行する必要があります。

ストレージ形式を変更するその他メリットは次のとおりです。

• スケーラビリティの向上（セグメントサイズの最適化）
• データストアのガベージの収集の迅速化
  
• 将来の機能強化に向けた基盤整備

オフラインでのリビジョンクリーンアップでは、最新の 2 世代のオンラインでのリビジョンクリーンアップと比較して、最新以外のすべての世代が再利用されます。新しいリポジトリがある場合、オフラインでのリビジョンクリーンアップ後に初めて実行したときに、再利用できる古い世代がないので、オンラインでのリビジョンクリーンアップでは領域を再利用できません。

また、の「オフラインでのリビジョンクリーンアップの後にオンラインでのリビジョンクリーンアップを実行する」の節も参照してください。 本章.

オンラインでのリビジョンクリーンアップは、AEM 6.3 以降のリリースでのみ使用できます。また、古いバージョンのAEMを使用している場合は、新しい Oak Segment Tar.

• リポジトリのサイズ
• システムへの負荷（リクエスト/分、特に書き込み操作）
• アクティビティパターン（読み取りと書き込み）
• ハードウェアの仕様（CPU パフォーマンス、メモリ、IOPS）

オンラインでのリビジョンクリーンアップ中、ディスク領域は継続的に監視されます。使用可能なディスク領域が重大な値を下回った場合、プロセスはキャンセルされます。 臨界値とは、リポジトリのその時点でのディスクフットプリントの 25%であり、変更はできません。

Adobeでは、最初に推定されたリポジトリサイズの 2 倍または 3 倍以上のディスクサイズを使用することをお勧めします。

クリーンアッププロセス中、空きヒープ領域が継続的に監視されます。空きヒープ領域が重大な値を下回った場合、プロセスはキャンセルされます。 臨界値は、org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD を使用して設定します。デフォルト値は 15% です。

最小コンパクションヒープサイズ設定のレコメンデーションは、AEM のメモリサイズ設定のレコメンデーションと切り離されていません。一般に： AEMインスタンスのサイズが、使用例とそれに対して予想されるペイロードに対応できるほど大きい場合、クリーンアッププロセスは十分なメモリを取得します。

• クリーンアップが毎日実行されていることを確認してください。
  
• 操作ダッシュボードでメンテナンスウィンドウを適切に設定して、リポジトリのアクティビティが最も少ない時間帯にクリーンアップが実行されるようにしてください。
• システムリソース（CPU、メモリ、I/O）を拡張してください。

リビジョンクリーンアップでは見積もりフェーズで、クリーンアップするのに十分なガベージがあるかどうかを判断します。見積もりでは、最後のコンパクション後のリポジトリのサイズと現在のサイズが比較されます。サイズが設定された差分を超えると、クリーンアップが実行されます。 サイズの差分は 1 GB に設定されています。つまり、前回のクリーンアップの実行以降にリポジトリのサイズが 1 GB 増加しなかった場合、新しいリビジョンクリーンアップの反復がスキップされます。

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

• リビジョン GC の実行： サイズデルタは N%または N/N （N/N バイト）なので、コンパクションが実行されています
• リビジョン GC が実行します not 実行： サイズデルタは N%または N/N （N/N バイト）なので、現時点では圧縮をスキップします

同時書き込みが可能なシステムでは、コンパクションサイクルの終了時に変更をコミットできるように、オンラインでのリビジョンクリーンアップで排他書き込みアクセスが必要になる場合があります。システムがに移行します 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 時間以下である必要があります。
• チェックポイントの数。コンパクションの実行時にチェックポイントが 3 つ以上ある場合は、チェックポイントをクリーンアップすることをお勧めします。

オンラインでのリビジョンクリーンアップが正常に完了したかどうかは、ログを確認して確認できます。

例：「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 の詳細に関しては、次の段落 を参照してください。

進行状況は、 EstimatedRevisionGCCompletion のフィールド名で追跡できます。 SegmentRevisionGarbageCollection MBean.

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

統計は、最後のシステム起動以降にのみ利用できます。 外部監視ツールを使用すると、AEMの稼動時間を超えてデータを保持できます。 詳細に関しては、 外部の監視ツールの例として、Nagios にヘルスチェックを接続するための AEM のドキュメントを参照してください。

• オンラインでのリビジョンクリーンアップが開始/停止しました
  • オンラインでのリビジョンクリーンアップは、推定、コンパクション、クリーンアップの 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 ログメッセージで示されます。

また、エラーメッセージに基づくトラブルシューティングの節を参照してください。

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

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

• リポジトリトラバーサルチェック
• クリーンアッププロセスが完了したら、oak-run ツールを使用して不整合をチェックします。この方法について詳しくは、 Apache ドキュメントを参照してください。 ツールを実行するために AEM をシャットダウンする必要はありません。

リビジョンのクリーンアップヘルスチェックは、 操作ダッシュボードの一部です。

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

それは イエロー オンラインでのリビジョンクリーンアップのメンテナンスタスクが 1 回キャンセルされた場合。

それは 赤 オンラインでのリビジョンクリーンアップのメンテナンスタスクが 3 回連続でキャンセルされた場合。 この場合、手動の操作が必要であるか、オンラインでのリビジョンクリーンアップが再び失敗する可能性が高くなります。詳細情報に関しては、以下のトラブルシューティングの節を参照してください。

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

スタンバイインスタンスで自動クリーンアップを監視する方法を教えてください。

ステータス、進行状況および統計は、 SegmentRevisionGarbageCollection MBean。 次の Oak ドキュメントも参照してください。

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

統計は、最後のシステム起動以降にのみ表示されます。 外部監視ツールを使用すると、AEMの稼動時間を超えてデータを保持できます。 また、 外部の監視ツールの例として、Nagios にヘルスチェックを接続するための AEM のドキュメントも参照してください。

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

スタンバイインスタンスでの自動クリーンアップ中に監視する必要があるものを教えてください。

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

• まず、ログエントリを確認します。
  
• ログの情報に応じて、適切なアクションを実行します。
  • ログに、5 回の失敗したコンパクションサイクルとforceCompactサイクルでのタイムアウトが示されている場合は、リポジトリへの書き込みが少ない、処理が少ない時間帯にメンテナンスウィンドウをスケジュールします。リポジトリの書き込みを、次の場所にあるリポジトリ指標監視ツールで確認できます。 https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
  • メンテナンスウィンドウの最後にクリーンアップが停止した場合は、メンテナンスタスクユーザーインターフェイスのメンテナンスウィンドウの設定が十分に大きいことを確認してください。
  • 使用可能なヒープメモリが不十分な場合は、インスタンスに十分なメモリがあることを確認します。
  • 応答が遅れた場合、セグメントストアが大きすぎて、メンテナンス期間が長くなってもオンラインでのリビジョンクリーンアップを完了できない可能性があります。 例えば、先週にオンラインでのリビジョンクリーンアップが正常に完了しなかった場合は、オフラインでのメンテナンスを計画し、オフラインでのリビジョンクリーンアップを実行して、セグメントストアを管理可能なサイズに戻すことをお勧めします。

A SegmentNotFoundException は、見つからなかったストレージユニット（セグメント）にアクセスしようとしたときに TarMK によって記録されます。 この問題を引き起こす可能性のあるシナリオは次の 3 つです。

1. 推奨されるアクセスメカニズム（Sling や JCR API など）を回避し、下位レベルの API/SPI を使用してリポジトリにアクセスし、セグメントの保持時間を超えるアプリケーション。 つまり、オンラインでのリビジョンクリーンアップで許可されている保持時間（デフォルトでは 24 時間）より長い間、エンティティへの参照を保持します。このケースは一時的なもので、データの破損にはつながりません。復旧するには、oak-run ツールを使用して、この例外が一時的なものである（oak-run チェックでエラーが報告されない）ことを確認する必要があります。これをおこなうには、インスタンスをオフラインにし、後で再起動する必要があります。
2. ディスク上のデータの破損を招いた外部イベント。これは、ディスク障害、ディスク容量不足、または必要なデータファイルの誤った変更などになります。この場合、インスタンスは、oak-run チェックを使用してオフラインにし、修復する必要があります。 oak-run チェックの実行方法についての詳細は、以下の Apache ドキュメント を参照してください。
3. その他すべての発生に対して、 Adobeカスタマーケア.

クリーンアップの実行時間は、リポジトリのサイズとクリーンアップが必要なリビジョンの数によって決まります。

• Oak リビジョン： Oak では、ノードとプロパティで構成される大規模なツリー階層ですべてのコンテンツを整理しています。このコンテンツツリーの各スナップショットまたはリビジョンは不変であり、ツリーの変更は新しいリビジョンのシーケンスとして表されます。通常、コンテンツを変更するたびに新しいリビジョンがトリガーされます。リンクをフォロー も参照してください。
• ページバージョン：バージョン管理では、特定の時点でのページの「スナップショット」が作成されます。通常は、ページがアクティベートされたときに新しいバージョンが作成されます。詳細情報に関しては、ページバージョンの処理 を参照してください。