AEM の内部インデックス作成プロセスでは、コンテンツを効率的に検索できるように、リポジトリデータが収集され Oak インデックスに保存されます。例外的な状況で、このプロセスが遅くなったり、停止したりすることがあります。このページは、インデックス作成に時間がかかっているかどうかを識別し、原因を特定し、問題を解決するためのトラブルシューティングガイドの役割を果たします。
必要以上に長時間がかかっているインデックス再作成と、コンテンツの量が膨大であるために処理に時間がかかっているインデックス再作成を区別することが重要です。例えば、コンテンツのインデックス作成にかかる時間はコンテンツの量に比例するので、大規模な実稼動リポジトリのインデックスを再作成するには小規模な開発リポジトリよりも時間がかかります。
コンテンツのインデックス再作成のタイミングおよび方法について詳しくは、クエリとインデックスに関するベストプラクティスを参照してください。
時間がかかっているインデックス作成を最初に検出するには、IndexStats
JMX MBean を確認する必要があります。影響を受ける AEM インスタンスで、次の手順を実行します。
Webコンソールを開き、「JMX」タブをクリックするか、https://<host>:<port>/system/console/jmxに移動します(例:http://localhost:4502/system/console/jmx)。
IndexStats
Mbeansに移動します。
「 async
」と「 fulltext-async
」のIndexStats
MBeansを開きます。
両方のMBeanに対して、完了タイムスタンプとLastIndexTimeタイムスタンプが、現在の時刻から45分未満かどうかを確認します。
いずれかの MBean で、時間値(Done または LastIndexedTime)が現在の時刻から 45 分以上前である場合は、インデックスジョブが失敗しているか、時間がかかりすぎています。これにより、非同期インデックスが古くなります。
強制終了によって、再起動後に AEM で非同期インデックス作成が最大 30 分停止し、通常は最初のインデックス再作成が完了するまでさらに 15 分かかり、合計で約 45 分が必要となります(最初の検出 の 45 分の時間枠を思い出してください)。強制終了後にインデックス作成が一時停止していることが疑われる場合は、次のことをおこなってください。
最初に、AEM インスタンスが強制的に終了した(AEM プロセスが強制的に kill された、または電源障害が発生した)後に再起動したかどうかを確認します。
強制終了が発生した場合、再起動後 AEM ではインデックス再作成が自動的に最大 30 分停止します。
AEM で通常の非同期インデックス作成操作が再開されるまで約 45 分待ってください。
AEM 6.1の場合、AEM 6.1 CFP 11がインストールされていることを確認します。
例外的な状況で、非同期インデックス作成の管理に使用されるスレッドプールが過負荷になることがあります。インデックス作成プロセスを分離するために、適当な時間でコンテンツにインデックス作成する Oak の機能に他の AEM の処理が干渉しないように、スレッドプールを設定できます。そのためには、次の手順を実行します。
Apache Sling Scheduler が非同期インデックス作成に使用する、分離された新しいスレッドプールを定義します。
Apache Sling Scheduler の新しいスレッドプールが登録され、Apache Sling Scheduler のステータス Web コンソールに表示されることを確認します。
AEM OSGi Webコンソール>Status>Slingスケジューラーに移動するか、https://<host>:<port>/system/console/status-slingscheduler(例:http://localhost:4502/system/console/status-slingscheduler)に移動します。
次のプールエントリが存在することを確認します。
リポジトリに非常に多くの変更とコミットが短時間におこなわれた場合、監視キューがいっぱいになることによってインデックス作成が遅延することがあります。まず、監視キューがいっぱいかどうかを確認します。
Webコンソールに移動し、「JMX」タブをクリックするか、https://<host>:<port>/system/console/jmxに移動します(例:http://localhost:4502/system/console/jmx)。
Oak リポジトリ統計 MBean を開き、いずれかの ObservationQueueMaxLength
値が 10,000 より大きいかどうかを確認します。
per second
セクションでは)最終的に 0 になる必要があるので、ObservationQueueMaxLength
の秒の指標が 0 であることを確認します。Consolidated Cache
統計MBeanのDocChildren
キャッシュの増加missRate
で確認できます。許容可能な監視キュー制限を超えないようにするには、次のことをお勧めします。
DiffCache
のサイズを大きくします。次の 2 つの状況下において、インデックス再作成は、「完全に動きがない」と見なすことができます。
インデックス再作成の速度が遅く、走査されたノード数に関する大きな進捗がログファイルで報告されない。
インデックス作成スレッドでログファイルに例外(OutOfMemoryException
など)が繰り返し出力されている場合、インデックス再作成は無限ループで動かなくなっている。ログに同じ例外が繰り返し表示される場合は、Oak が同じコンテンツのインデックスを繰り返し作成しようとして、同じ問題で失敗していることを示しています。
動きがないインデックス再作成プロセスを識別および修正するには、次の手順を実行します。
インデックス作成が動かない原因を識別するためには、次の情報を収集する必要があります。
2 秒ごとにスレッドダンプを取得し、5 分間収集します。
非同期IndexStats
MBeanからデータを収集します。
AEM OSGi Web Console>Main>JMX>IndexStat>asyncに移動します。
oak-run.jarのコンソールモードを使用して、* /:async
*ノードの下に存在する内容の詳細を収集します。
CheckpointManager
MBeanを使用して、リポジトリチェックポイントのリストを収集します。
AEM OSGi Web Console>Main>JMX>CheckpointManager>listCheckpoints()
手順1で説明したすべての情報を収集した後、AEMを再起動します。
async, async-reindex
およびulltext-async
インデックスレーン(IndexStats
Mbean)を介して、再インデックスを安全に中止(完了する前に停止)できます。 詳しくは、再インデックスを中止する方法に関するApache Oakのドキュメントも参照してください。 また、次の点も考慮してください。
PropertyIndexAsyncReindexMBean
を介して再インデックスが開始された場合にのみ中止できます。インデックス再作成を安全に中止するには、次の手順に従います。
停止する必要があるインデックス再作成レーンを制御する IndexStats MBean を識別します。
AEM OSGi Webコンソール>Main>JMXまたはhttps://<host>:<port>/system/console/jmx(例:http://localhost:4502/system/console/jmx)に移動し、JMXコンソールを介して適切なIndexStats MBeanに移動します。
停止する再インデックス付けレーン(async
、async-reindex
、またはfulltext-async
)に基づいてIndexStats MBeanを開きます。
async
、async-reindex
、またはfulltext-async
。適切なIndexStats
MBeanでabortAndPause()
コマンドを呼び出します。
インデックス付けレーンの再開時に再インデックスを再開しないように、Oakインデックス定義を適切にマークします。
既存のインデックスを再インデックスする場合、reindexプロパティをfalseに設定します
/oak:index/someExistingIndex@reindex=false
あるいは、新規インデックスの場合は次のようにします。
type プロパティを無効に設定します。
/oak:index/someNewIndex@type=disabled
または、インデックス定義を完全に削除します。
完了したら、変更をリポジトリにコミットします。
最後に、中止したインデックス作成レーンで非同期インデックス作成を再開します。
abortAndPause()
コマンドを発行したIndexStats
MBeanで、resume()
コマンドを呼び出します。静かな時間帯(大きなコンテンツの取り込み時など)に再インデックスを行うのが最適で、AEMの読み込みと制御が行われるメンテナンス時間帯に最適です。 また、インデックス再作成が他のメンテナンスアクティビティ中に実行されないようにしてください。