フルテキスト検索に lucene を使用している jcr リポジトリ (サーブレット コンテナが埋め込まれている) があります。検索クエリは、検索結果が返された後でもかなりの時間、CPU 使用率のスパイクを引き起こしているようです。スレッド ダンプを調べたところ、Lucene Merge スレッドが CPU のスパイクを引き起こしていることがわかりました。
"Lucene Merge Thread #0" daemon prio=10 tid=0x000000005fd95000 nid=0x5add runnable [0x0000000049fc8000]
java.lang.Thread.State: RUNNABLE
at org.apache.lucene.store.IndexOutput.writeVInt(IndexOutput.java:70)
at org.apache.lucene.index.FormatPostingsPositionsWriter.addPosition(FormatPostingsPositionsWriter.java:70)
at org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:701)
at org.apache.lucene.index.SegmentMerger.mergeTermInfos(SegmentMerger.java:635)
at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:573)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:156)
at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4443)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4000)
at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:231)
at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:288)
そして、動作は非常に一貫しています。検索クエリが繰り返しマージをトリガーするように見えます (最終的には検索自体が遅くなります)。これは、検索がインデックス マージをトリガーする理由を理解するのが難しいです。
もう 1 つの関連する質問は、検索クエリが一定期間にわたって遅くなることです。サーバーを新たに再起動した後、lucene クエリは約 300 ～ 400 ミリ秒で返されますが、サーバーが 1 週間実行されている場合、同じクエリに 3 ～ 4 秒、またはそれ以上かかる場合があります。CPUとメモリをチェックしました。サーバーがアイドル状態の場合、CPU 使用率は通常 (1% 未満) ですが、いくつかの検索でかなり長い間 CPU 使用率が 100% になります (上記を参照)。サーバーには 12g のメモリがあり、そのうち 4g のみが現在使用されています (メモリの問題はありません)。次に、サーバーがしばらく実行されていると（再起動と比較して）検索が遅くなるのはなぜですか?? それは、時間の経過とともにキャッシュがゆっくりと読み込まれ、キャッシュに対して線形スキャンが実行されているためですか（ただし、キャッシュの取得は非常に高速であると想定されています-キャッシュのまさに目的です）[編集済み] JCR 2をサポートするCRX 2.3. 0 (JSR 283 仕様)。リポジトリには約 40,000 個のファイルがあり、そのうち約 15,000 個は全文のインデックスが作成された pdf です。