AEM の Oak リポジトリは、MongoDB および夜間メンテナンスタスクを使用するように設定されており、リビジョンクリーンアップは完了まで 5 時間かかります。

原因

次のようなさまざまな原因が考えられます。

  1. 過去24時間内のリポジトリへの多数の書き込み。
  2. MongoDB のパフォーマンスの問題。

解決策

Oak リポジトリへの過剰な書き込みによって、リビジョンのガベージコレクションが発生した場合は、次の方法でデバッグできます。

  1. http://aem-host:port/system/console/slinglog にアクセスして、管理者としてログインしてください。

  2. ロガーを追加します。

    • ログファイル:revisiongc.log
    • ログレベル:デバッグ
    • ロガー:org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector
  3. 次の低速なリビジョンのクリーンアップが発生するまで待ちます。

  4. この bash スクリプトをログファイルに対して実行して、クリーンアップされた更新のカウントを取得します:cut -d ':' -

    -f2,3 revisiongc.log | grep '/' | cut -f1-7 -d '/' | sed 's|\(/etc/workflow/.*/2015-09-[0-9]*\)[_0-9]*\(/.*\)_[0-9]*|\1\2|' | sed 's|\(/var/replication/data/[a-z0-9\-]*\).*|\1|' | sort | uniq -c | sort -nr | less

    出力の例(さまざまなパスで削除されたアイテムの数を表示):

    1574323 /oak:index/slingeventEventId/
    140203 /oak:index/slingResourceType/
    130687 /oak:index/nodetype/
    130557 /oak:index/event.job.topic/
    37277 /oak:index/reference/
    35870 /var/replication/data/4e8f3d96-c010-4d2c-bf7b-431b902880d2
    ...

  5. このデータを使用すると、更新頻度が高すぎるインデックスを削除できるかどうかを確認できます。これにより、リポジトリ内で最も一時的な更新が行われる場所を確認できます。この情報を使用することで、過剰な数の Oak への書き込みを減らすことができます。

  6. Revision GC が低速で、システムのインデックスや他の場所の Oak に対する過剰な書き込みが見つからない場合は、MongoDB のパフォーマンスを調べることができます。Revision GC は、常にプライマリ MongoDB の複製と実行することで、mongod.log で使用されたクエリーの回数およびインデックスを検索することができます。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー