Solrのクエリがフルヒープを使用し、STW（Stop The World）ポーズを引き起こす
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/qw25bzxpjyz1ncfms89y6x2pozjcnkn1 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、Solrユーザーと開発者の皆さん、
LTR（Learning to Rank）をリランカーとして使用したSolrクエリが突然フルヒープを使用し、STWポーズを引き起こしています。これについてご意見をいただけますでしょうか？この問題の原因は何でしょうか？STWがノードを不健全な状態にして再起動を引き起こし、クラスタ全体がダウンしています。
ログによると、問題はクエリ時に生成されるLTRの特徴量に関連しているようです。モデルには12の特徴量があり、その多くはSolrクエリであり、いくつかはフィールドの値です。以下にエラーログを示します[2]。この現象は重大なバグだと思われます。というのも、G1GCはSTWを避けるべきだからです。皆さんのご意見をお聞かせください。
[1] クエリの例:
q=((color) OR (colorable AND colourable) OR (colorant) OR (colorata) OR (colorear) OR (colored) OR (colorete) OR (colorie) OR (coloring AND colouring) OR (colors) OR (colour) OR (colourfulness) OR (colourations) OR (coloured) OR (colourful) OR (colouring) OR (colourist AND colorist) OR (complexion) OR (dyestuffs) OR (flush) OR (hue) OR (paint) OR (people) OR (rosy) OR (stainable) OR (stained) OR (colored) OR (coloring) OR (tinted) OR (turn) OR (colora))
&defType=edismax&qf=keywords description title body&rq={!ltr model=v1_20230302_model reRankDocs=1000 efi.q=$q}
[2] エラーログの抜粋:
org.apache.solr.common.SolrException: java.lang.RuntimeException: Exception from createWeight for SolrFeature [name=keyword_pf3, params={q={!edismax qf=keyword pf3=keyword^0.2}${q}}]
The request took too long to iterate over terms. Timeout: timeoutAt: 2027319049754068 (System.nanoTime(): 2027323098817134),
TermsEnum=org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnum@1155724b
=> org.apache.solr.common.SolrException: java.lang.RuntimeException: Exception from createWeight for SolrFeature [name=keyword_pf3, params={q={!sdismax qf=keyword_pf3=keyword^0.2}${q}}]
The request took too long to iterate over terms. Timeout: timeoutAt: 2027319049754068 (System.nanoTime(): 2027323098817134),
TermsEnum=org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnum@1155724b
at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:163)
G1GCは完全にはSTW（Stop-The-World）を排除できません。
G1GCの動作の詳細の1つは「巨大オブジェクト」と呼ばれるものに関連しています。
G1領域サイズの半分以上のオブジェクトは「巨大」と分類され、これらは直接古い領域に割り当てられます。そして、それらを収集する唯一の方法はフルGC時です。
G1GCの高いパフォーマンスの秘訣は、フルGCサイクルをできるだけ減らすことです。フルGCでは必ず長いSTWが発生しますが、G1の領域ごとの収集はほぼアプリケーションと並行して行われます。
GCチューニングで-XX:G1HeapRegionSizeパラメータを使ってG1領域のサイズを設定できますが、最大サイズは32MBです。したがって、16MB以上のオブジェクトは常に「巨大」となります。LTR（Learning to Rank）モデルは多くの場合数MBのサイズになると聞いていますが、私自身は使用したことがありません。
Java 11以降を使っている場合は、ZGC（Z Garbage Collector）を試してみることをお勧めします。私はOpenJDK 17を使っており、以下のチューニングを/etc/default/solr.in.shで使用しています：
GC_TUNE=" -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:+ParallelRefProcEnabled -XX:+ExplicitGCInvokesConcurrent -XX:+AlwaysPreTouch -XX:+UseNUMA "
ZGCは、たとえテラバイトサイズのヒープであっても、非常に短いGCポーズを保証します。私は大きなヒープでは試していませんが、限られたテストでは、G1よりもポーズが非常に短かったです。スループットはG1より低いですが、レイテンシは素晴らしいです。
1つの注意点として、ZGCは常に64ビットポインタを使用するため、一般的に見かける32GB未満のヒープを推奨するアドバイスはZGCには適用されません。ZGCでは、31GBと32GBのヒープサイズに違いはありません。
よろしくお願いします。
Shawn
Shawn、ありがとうございます。とても参考になりました。
G1HeapRegionSizeの設定を試してみました。32m（XX:G1HeapRegionSize=32m）に設定し、同じクエリログを再生しましたが、効果はなく、同じOOMエラーが再現されました。
ヒープがほぼいっぱいになったときにヒープダンプをキャプチャすることができ、MAT（Memory Analyzer Tool）で生成されたヒープ分析レポートをこちらのドライブにアップロードしました。
レポートリンク
お時間があるときにぜひご覧いただき、感想をお聞かせいただけると嬉しいです。クエリでLTRをリランカーとして使用しているときにのみ問題が再現されますが、レポートによると、問題の根本はメインライブラリに起因しているようです。どう思われるか教えてください。
ZGCをテストして、STWや古い世代のフルGCを防げるか確認してみます。結果が分かり次第お知らせします。
よろしくお願いします、
Rajani
reRankDocsが1000に設定されています。100のような低い値にしてみると良いかもしれません。最良のマッチが上位100件のドキュメントに含まれない場合は、基本的な関連性アルゴリズムに何か問題がある可能性があります。
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)
こんにちは、Wunderさん、
ベースランカーは、qf、pf2、pf3に基づいてドキュメントのマッチングとランキングを行い、LTRリランカーは日付（最新性）、人気、保存、フェイバリットなどのユーザー行動フィールド/特徴を考慮します。そのため、1000件の再ランキングを行うことで、トップ100件よりも高品質な結果が得られます。
ありがとうございます。
Rajani
100で試してみて、ヒープメモリが不足するか確認してください。もし不足しなければ、reRankDocsのサイズが原因です。
ヒープを増やすこともできますが、リランカーが結果リストの中で1000位以内のドキュメントを動かしているのであれば、ベースの関連性を改善することを真剣に検討した方がよいでしょう。例えば、全体の人気度を集計に含めたり、全体的な最新性を追加することを検討してください。
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)
トピックへ返信するには、ログインが必要です。