Oak インデックスのトラブルシューティング troubleshooting-oak-indexes

Web コンソールを開いて「JMX」タブをクリックするか、https://<ホスト>:<ポート>/system/console/jmx（例：http://localhost:4502/system/console/jmx）に移動します。

IndexStats Mbean に移動します。

「async」および「fulltext-async」の IndexStats MBean を開きます。

両方の MBean で、Done タイムスタンプおよび LastIndexTime タイムスタンプが現在の時刻から 45 分以内であるかどうかを確認します。

いずれかの MBean で、時間値（Done または LastIndexedTime）が現在の時間から 45 分より大きい場合は、インデックスジョブが失敗しているか、時間がかかりすぎています。これにより、非同期インデックスが古い状態になります。

まず、AEMインスタンスが強制的にシャットダウンされたか (AEMプロセスが強制的に強制的に終了したか、電源障害が発生したか )、その後再起動されたかを確認します。

• そのために、AEM のログを参照してください。

強制シャットダウンが発生した場合、再起動時に、AEMは自動的に最大 30 分間インデックス再作成を中断します。

AEMが通常の非同期インデックス作成操作を再開するまで、約 45 分待ちます。

非同期インデックス作成に使用する Apache Sling Scheduler 用の新しい分離スレッドプールを定義します。

• 影響を受ける AEM インスタンスで、AEM OSGi web コンソール／OSGi／設定／Apache Sling Scheduler に移動するか、https://<ホスト>:<ポート>/system/console/configMgr（例：http://localhost:4502/system/console/configMgr）に移動します。
• 「許可されたスレッドプール」フィールドに、値が「oak」のエントリを追加します。
• 右下の「保存」をクリックして、変更を保存します。

Apache Sling Scheduler の新しいスレッドプールが登録され、Apache Sling Scheduler のステータス web コンソールに表示されていることを確認します。

• AEM OSGi web コンソール／ステータス／Sling Scheduler に移動するか、https://<ホスト>:<ポート>/system/console/status-slingscheduler（例：http://localhost:4502/system/console/status-slingscheduler）に移動します。

• 次のプールエントリが存在することを確認します。

  • ApacheSlingoak
  • ApacheSlingdefault

web コンソールに移動して「JMX」タブをクリックするか、https://<ホスト>:<ポート>/system/console/jmx（例：http://localhost:4502/system/console/jmx）に移動します。

Oak リポジトリ統計 MBean を開き、いずれかの ObservationQueueMaxLength 値が 10,000 より大きいかどうかを確認します。

• 通常の操作では、この最大値は（特に per second セクションでは）最終的に 0 になる必要があるので、ObservationQueueMaxLength の秒の指標が 0 であることを確認します。
• 値が 10,000 以上で、徐々に増加する場合は、少なくとも 1 つ（場合によっては増加）のキューを新しい変更（コミット）が発生するほど速く処理できないことを示します。
• 各監視キューには制限（デフォルトでは 10,000 個）があり、その制限に達すると処理が低下します。
• MongoMK を使用している場合は、キューの長さが長くなるにつれて内部 Oak キャッシュのパフォーマンスが低下します。この相関関係は、Consolidated Cache 統計 MBean の DocChildren キャッシュの missRate が増加していることで確認できます。

許容可能な監視キューの制限を超えないようにするには、次の操作をお勧めします。

• コミットの一定率を下げます。 コミットの短いスパイクは許容できますが、一定の速度を下げる必要があります。
• Performance tuning tips／Mongo Storage Tuning／Document cache size の説明に従って、DiffCache のサイズを大きくします。

インデックス作成が停止した原因を特定するには、次の情報を収集する必要があります。

• 5 分間のスレッドダンプを収集し、2 秒ごとに 1 つのスレッドダンプを収集します。

• アペンダーの DEBUG レベルとログの設定.

  • org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate
  • org.apache.jackrabbit.oak.plugins.index.IndexUpdate

• 非同期 IndexStats MBean からデータを収集します。

  • AEM OSGi web コンソール／メイン／JMX／IndexStat／async に移動します。

    または、http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DIndexStats に移動します。

• oak-run.jar のコンソールモードを使用して、/:async ノードに存在する内容の詳細を収集します。

• CheckpointManager MBean を使用して、リポジトリチェックポイントのリストを収集します。

  • AEM OSGi web コンソール／メイン／JMX／CheckpointManager／listCheckpoints()

    または、http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DSegment+node+store+checkpoint+management%2Ctype%3DCheckpointManager に移動します。

手順 1 に示されているすべての情報を収集した後、AEM を再起動します。

• 同時負荷が高い場合（監視キューのオーバーフローなど）は、AEM を再起動すると問題が解決することがあります。
• 再起動しても問題が解決しない場合は、アドビサポートに問題を提出し、手順 1 で収集したすべての情報を提供してください。

停止する必要があるインデックス再作成レーンを制御する IndexStats MBean を識別します。

• AEM OSGi web コンソール／メイン／JMX、または https://<ホスト>:<ポート>/system/console/jmx（例：http://localhost:4502/system/console/jmx）に移動して、JMX コンソールから該当する IndexStats MBean に移動します。

• 停止するインデックス再作成レーン（async、async-reindex、 fulltext-async）にもとづいて IndexStats MBean を開きます。

  • 該当するレーンを識別し、IndexStats MBean インスタンスを特定するには、Oak インデックスの「async」プロパティを確認します。「async」プロパティにはレーン名が示されています（async、async-reindex、fulltext-async のいずれか）。
  • レーンは、「Async」列のAEM Index Manager にアクセスしても使用できます。 インデックスマネージャにアクセスするには、操作/診断/インデックスマネージャに移動します。

適切な IndexStats MBean で abortAndPause() コマンドを呼び出します。

インデックス作成レーンの再開時にインデックス再作成が再開されないように、Oak インデックス定義を適切にマークします。

• 既存の ​インデックスを再作成する場合は、reindex プロパティを false に設定します。

  • /oak:index/someExistingIndex@reindex=false

• または、 新規 インデックス：

  • type プロパティを disabled に設定します。

    • /oak:index/someNewIndex@type=disabled

  • または、インデックス定義を完全に削除します。

完了したら、変更をリポジトリにコミットします。

最後に、中止されたインデックス作成レーンで非同期インデックス作成を再開します。

• 手順 2 で abortAndPause() コマンドを発行した IndexStats MBean で、resume() コマンドを呼び出します。