AEM オンプレミス：ディスク領域が不足しているため、セグメントストアのクリーンアップに失敗しました
✨ このコンテンツはAIが生成したもので、不正確である可能性があります。 生成AI用語
この記事では、セグメントストアがファイルシステムの制限に近づいたときに、Adobe Experience Manager（AEM）オンプレミス環境で自動リビジョンクリーンアップが失敗する理由と、問題を解決するための手順の概要を説明します。
説明 description
環境
Linuxを実行しているパブリッシュサーバー上のApache Jackrabbit Oak 1.22.20を使用するAdobe Experience Manager （AEM） 6.5.21.0。
症状
- セグメントストアのサイズは、ファイルシステムの制限値近くまで増加します（550 GBのファイルシステムでは421～425 GBなど）。
- 自動リビジョンクリーンアップ（TarMK コンパクション）が失敗し、利用可能なディスク容量が不足しているため実行されません。
- リポジトリのサイズは拡大し続けており、セグメントストアディレクトリに追加のストレージは使用できません。
- オフラインコンパクションを実行しようとすると、ディスクのヘッドルームが不足しているためブロックされます。
- エラーログには、次のようなコンパクションキャンセルが繰り返し表示されます。
- 「TarMK GC #: コンパクションがキャンセルされました：十分なディスク容量がありません。」
- クリーンアッププロセスでは0Bが再利用され、セグメントストアのサイズは引き続き増加します。
- ディスク使用コマンド （例：
du -sh repository/segmentstore）は、セグメントストアのサイズを確認します。
再現手順
- セグメントストアは、ファイルシステムの制限に近づくまで拡張できます。
- 自動またはオフラインのリビジョンクリーンアップを実行しようとしました。
- ディスク領域が不足しているため、コンパクションの失敗を監視します。
原因
新しいセグメント生成を作成するのに十分なディスク容量がない場合、OakがTarMK テールコンパクションをキャンセルするため、自動リビジョンクリーンアップが失敗します。 コンパクションが成功しない場合、古いセグメントデータは再利用できず、ディスク容量が不足するまでセグメントストアが拡張されます。
解決策 resolution
問題を解決するには、次の手順に従います。
-
AEMの実行中に
repository/segmentstoreからファイルを手動で削除しないでください。これは、リポジトリの破損の原因となる可能性があります。 -
最近の復元可能なバックアップと十分な一時ディスク領域がなければ、オフラインのコンパクションを実行しないでください。
-
ファイルシステム容量を増やすか、コンパクション作業セットに十分な一時的なストレージを提供します。
-
永続的な拡張が不可能な場合は、インフラストラクチャチームと協力して一時的なボリュームをリポジトリの場所にマウントするか、メンテナンスウィンドウ中に十分なスペースがあるボリュームにリポジトリを再配置します。
-
一時的なボリュームに、完全なコンパクション操作に十分な使用可能な容量とパフォーマンスがあることを確認します。
-
可能であれば、マウントまたはリロケーション計画を非実稼動環境でテストします。
-
コンパクションまたはクリーンアップ処理の前に、AEM インスタンスのバックアップを作成して検証します。 バックアップは、作業用ストレージとは別に保存します。
-
Oak Runの互換性を確認：デプロイされたOak コアバージョンと一致するOak Run バージョンを使用します（例：Oak 1.22.20には
oak-run-1.22.20.jarが必要です）。 旧バージョンのOak Runをコンパクションに使用しないでください。 詳しくは、Oakのドキュメントを参照してください。 -
十分な容量を確保できたら、リビジョンのクリーンアップを実行するか、続行します。
-
次のようなコンパクションとスペースの再利用が成功したログを確認します。
- 「コンパクションに成功しました」
- 「クリーンアップ完了」
- 「スペースが0 Bを超えて再利用されました」
- 「RevisionCleanupTaskが正常に完了しました」
-
オンラインクリーンアップで領域を復元できない場合は、対応するOak Run バージョンとAdobeでサポートされている手順を使用して、AEMを停止して、制御されたオフラインの完全なコンパクションを実行します。
-
回復後、チェックポイントの保持、リポジトリの書き込みアクティビティ、ワークフロー/インポート、インデックス作成アクティビティ、およびメンテナンスタスクの履歴を確認して、リポジトリの増加の原因を調査します。