SolrのJVMヒープがいっぱいになり、再起動を試みると停止します。
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/1x8f96wmmfbbm3dmy9d28sq8p9nk05m4 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
みなさん、こんにちは。
我々は3つのクラスターSolrをそれぞれ異なるマシンで実行しており、インデックスサイズは300 GBです。
RAM: ノードごとに300 GB
Heap - Xms: 240GB Xmx: 300GB
インデックスサイズ: 300GB
GC_TUNE="-XX:+UseG1GC
-XX:InitiatingHeapOccupancyPercent=45
-XX:ConcGCThreads=6
-XX:ParallelGCThreads=30
-XX:G1ReservePercent=20
<autoCommit>
<maxTime>${solr.autoCommit.maxTime:400000}</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
</autoSoftCommit>
私たちのクラウドサーバーは昨日突然停止しました。再起動を試みると、JVMヒープサイズが数秒で最大の300 GBになり、次のメッセージが表示されてから自動的に停止します。
GC実行前のヒープ呼び出し=0 (フル0):
ガベージファーストヒープの合計 251658240K、使用済み 360448K [0x00007eba80000000、0x00007eba8200f000、0x00007f0580000000]
リージョンサイズ 32768K、若い世代 12 (393216K)、生存者 0 (0K)
Metaspace使用 20504K、容量 21158K、割り当て済み 21248K、予約済み 22528K
2021-05-10T05:31:59.511+0000: 3.036: [GC一時停止（メタデータGC閾値）（若年期）（初期マーク）
希望する生存者サイズは805306368バイト、新しい閾値は15（最大15）
{GC実行前のヒープ呼び出し=11（フル0）：
ガベージファーストヒープの合計 288849920K、使用済み 20398080K [0x00007eba80000000、0x00007eba82011378、0x00007f0580000000]
リージョンサイズ 32768K、若年世代 440（14417920K）、生存者 54（1769472K）
Metaspace使用 58413K、容量 61495K、割り当て済み 61696K、予約済み 63488K
2021-05-10T05:33:15.477+0000: 79.002: [GC一時停止（G1 Evacuation Pause）（若年期）
希望する生存者サイズは922746880バイト、新しい閾値は1（最大15）
- 年齢1：1043976736バイト、合計1043976736
- 年齢2：766998080バイト、合計1810974816
、0.4319767秒]
[並行時間：408.3 ms、GCワーカー：30] [GCワーカー開始（ms）：最小：79002.5、平均：79003.0、最大：79003.6、Diff：1.2]
[Ext Root Scanning（ms）：最小：0.1、平均：0.8、最大：2.7、Diff：2.6、合計：23.7] [Update RS（ms）：最小：0.0、平均：1.7、最大：3.1、Diff：3.1、合計：51.7]
[処理されたバッファ：最小：0、平均：3.8、最大：17、Diff：17、合計：113] [Scan RS（ms）：最小：13.9、平均：15.8、最大：16.7、Diff：2.8、合計：474.0]
[Code Root Scanning（ms）：最小：0.0、平均：0.1、最大：2.1、Diff：2.1、合計：4.3] [オブジェクトのコピー（ms）：最小：385.5、平均：387.5、最大：390.6、Diff：5.1、合計：11624.2]
[終了（ms）：最小：0.1、平均：0.5、最大：0.9、Diff：0.9、合計：13.8] [終了試行回数：最小：1、平均：82.1、最大：172、Diff：171、合計：2464]
[GCワーカーその他（ms）：最小：0.0、平均：0.1、最大：0.4、Diff：0.4、合計：3.6] [GCワーカー合計（ms）：最小：405.9、平均：406.5、最大：407.3、Diff：1.4、合計：12195.3]
[GCワーカー終了（ms）：最小：79409.4、平均：79409.5、最大：79409.8、Diff：0.4] [コードルートの修正：0.1 ms]
[コードルートの削除：0.0 ms] [CTのクリア：6.7 ms]
[その他：16.9 ms] [Choose CSet：0.0 ms]
[参照処理：5.2 ms] [参照エンキュー：0.0 ms]
[Redirty Cards：9.2 ms] [Humongous Register：0.3 ms]
[Humongous Reclaim：0.0 ms] [Free CSet：0.7 ms]
この問題を解決するのに役立ててください！
ありがとうございます！
よろしくお願いします！
Vigz
こんにちは、Vigzさん、
300GBのRAMマシンをお使いの場合、OSがファイルをキャッシュするための余裕を残すために、ヒープサイズを下げることが望ましいでしょう。また、JVMの実際のメモリ使用量はおそらくRAMを超えることになります。その場合、JVMのメモリはスワップに行くか、スワップが無効になっている場合はOSがプロセスを終了します（おそらくこの場合が該当しますが、dmesgで再確認できます）。
また、300GBのインデックスに300GBのヒープサイズが必要かどうか疑問です。ほとんどのユースケースでは、30GBのヒープサイズが十分であるはずです。
まず試してみてほしいことは次の通りです：
- ヒープサイズを下げる。半分（150GB）から始めて、そこから調整します。実際のヒープ使用量を監視し（私たちはそれを行うツールを持っています、リンクは私の署名にあります）、さらに調整します。30GB以上必要と思われる場合は驚きます。
- 最近のJavaバージョンをお使いの場合（Java 11をお勧めします）、G1GCのデフォルト設定はかなり合理的です。したがって、大きなボックス（おそらくあなたが持っているもの）を持っている場合は、ConcGCThreadsとParallelGCThreadsを削除し、Javaのデフォルトに頼ることができます。
最後に、より頻繁にハードコミットを行うことがあります（autoCommit → maxSizeを100m程度に設定し、そこから調整します）。また、アプリケーションからのコミットではなく、autoSoftCommitを使用することも検討してください。
よろしくお願いします。
Radu
SolrとElasticsearchのコンサルティング、トレーニング、およびプロダクションサポート
こんにちは、Radu
返信いただきありがとうございます。
おっしゃるように、Java 11に変更し、Solrのデフォルトに戻し、ConcGCThreadsとParallelGCThreadsを削除しましたが、問題は変わりませんでしたね。
30GB、150GB、250GBなど、ヒープを複数回変更してみましたが、効果がありませんでした。Solrは再起動後5分以内に停止し、JVMヒープがいっぱいになるため、回復できないようです。すべてのサーバーでJVMが占有されているようです。
Solrの問題については明確にわかりませんね。何か提案はありますか？
よろしくお願いします。
こんにちは、
さらにヒープをさらに削減してみてください。30GBはまだ非常に高いです。たとえば、私たちの最大のインデックスは合計で約50GBです。4つのシャードと3つのレプリカに分割されており、各ノードはたったの3.5GBのヒープで問題なく動作し、それぞれ2つのレプリカを提供しています。
ヒープサイズを下から上に調整してみるのも良いでしょう。OutOfMemoryエラーが発生した場合にわかるはずです。
よろしくお願いします。
Markus
そのヒープはあまりにも大きすぎます。Solrはインデックス全体をJVMヒープに読み込みません。ファイルバッファにインデックスを保持するために、ヒープ以外のRAMが必要です。
次の設定で再試行してみてください：
-Xms16G
-Xmx16G
それでメモリが不足する場合は、31Gを試してみてください。
サーバープロセスの開始時と最大のヒープサイズは常に同じである必要があります。JVMはフルGCの前に最大値まで増加します。
また、30個のGCスレッドは不要です。デフォルト値を使用してください。
最後に、このリストは画像を削除するので、誰も画像を見ることができませんでした。画像をアップロードしてリンクしてください。
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ （私のブログ）
これまでのアドバイスに加えて、適用可能であれば、スワップを無効にすることを強くお勧めします（特に望んでいた効果が得られなかった場合）：
https://solr.apache.org/guide/8_8/taking-solr-to-production.html#disabling-swap
あなたのケースに関連する可能性が高いが、仮想メモリ、スワップ、およびガベージコレクションに関する良いバックグラウンドリーディングがこちらにあります：
https://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
ほとんどの場合、過度なJVMの使用は、多くのドキュメントを持つインデックスと非常に大きなフィルターキャッシュに起因します。このフィルターキャッシュは、オートウォームによって一度にブローされるか、ほとんどヒットしないために時間の経過とともに徐々に増加します。その観点から：
1) インデックスには何件のドキュメントがありますか？
2) フィルターキャッシュの設定はどのようになっていますか？ （およびオートウォームの設定はどうですか？）
3) 典型的なクエリを提供できますか？ ソルのログからコピーされたものが望ましいです。すべてのパラメーターを確認できます。
最悪の場合、フィルターキャッシュのエントリ数は、インデックス内のドキュメント数と同じ数のビットです。例えば、インデックスに6400万のドキュメントがある場合、エントリは8メガバイトになります。フィルターキャッシュの最大サイズが40,000で、同じ数のエントリをオートウォームする場合、（非常に大きな）ヒープがSolrを再起動するときにいっぱいになります。
Toke Eskildsen
トピックへ返信するには、ログインが必要です。