突然のスレッド数の増加
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/0kpo3y4d632pwwfvpbhg8903d21ypy7h into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
私は一定期間Solrを使用していますが、スレッドに関する問題に直面しています。
私はSolrクラウドを稼働させており、合計で4つのコレクションがあり、それぞれのコレクションには約600のシャード（それぞれ2つのレプリカを持つ）があります。
最近、"out of memory, cannot create native thread" のエラーが発生し始め、スレッドダンプを取得したところ、問題が発生するときにはコアごとに800〜1000のオープンスレッドがあることがわかりました（通常、100〜500のオープンスレッドがあります）。
これらのオープンスレッドのうち、絶対多数（80〜90%）は次のような名前を持っています：
"CloudSolrStream-[number]-thread-[number]-processing-n:[current-solr-live-node] x:[core] s:[shard] c:[collection] r:[node]"
しかし、私たちのログを確認したところ、特にこのような急激な増加を引き起こすストリームリクエストはありませんでした。
これらのエラーは毎日発生しています。
なぜこれが起こるのか、または何を調査すれば良いかについてのアイデアをいただけると助かります。
CloudSolrStreamは、各シャードのレプリカに対してSolrStreamを作成するためにスレッドプールを使用します。各スレッドは1つのレコードを返した後に終了しますが、各シャードの初期検索はスレッド内で完了します。1つのレコードが返されると、結果を各シャードからマージするための単一のスレッドが使用されます。しかし、初期のスレッドプールはシャードの数だけ大きくなります。そのため、ストリームの呼び出しが少し増えるだけでも、スレッドの数が大幅に増加します。
「ワーカー」コレクションを追加することで、非常に大規模なスケーリングが可能です。このコレクションにはデータを保持せず、単にストリーミング式を実行します。すべてのストリームリクエストをこのコレクションに送信します。このコレクションはデータを保持しないため、ノードには多くのディスクスペースが必要ありません。必要に応じて簡単にスケールアップおよびスケールダウンすることができます。ストリーミング式は、指定された関数内でどのコレクションでもクエリを実行しますが、CloudSolrStreamによって作成されるスレッドはワーカーコレクションのノード内で作成されます。
Joel Bernstein
http://joelsolr.blogspot.com/
ありがとうございます！
理解していることを確認しますね：
私は "https:///solr//stream" に対してリクエストを送信し、"expr=search(<col-1, ....)" を実行します。その後、内の各シャードに対して、私の がスレッドを開き、各シャードのレプリカにリクエストを送信します。
各レプリカはリクエストを受け取り、でクエリを実行し、その結果をに返します。そして、はすべての結果を集めますか？
最近変更した唯一の変更は、いくつかのシャードにレプリカを追加したことです（各コレクションには空の範囲のシャードがあり、ユーザーはこれらのシャードにリクエストを送信します。これらのシャードに追加のレプリカを追加しました）。あなたの説明によると、これらのレプリカを追加することはスレッドの作成に影響を与えないということですね？
小規模なインストールでも、デフォルト設定のOSには問題を引き起こす程のスレッドを簡単に開始できます。ほとんどのオペレーティングシステムはデフォルトで1024個の制限になっています。これには以前にも遭遇したことがありますが、それらのシステムはスタンドアロンモードで動作していたので、おそらくクラウドモードであればより多くのスレッドが生成されるでしょう。
Solrを実行しているユーザーには、より多くのプロセス／スレッドとより多くのオープンファイルを許可する必要があります。Linuxの場合、以下のような行を /etc/security/limits.conf に追加することができます：
solr hard nofile 8192
solr soft nofile 8192
solr hard nproc 8192
solr soft nproc 8192
もしくは、システムに /etc/security/limits.d ディレクトリがある場合は、/etc/security/limits.d/solr.conf を作成し、上記の設定をそのファイルに配置することができます。
Linuxで制限を増やした後は、再起動が必要な場合もありませんが、安全策として行うことをお勧めします。
Linux以外の場合、制限を増やす方法については分かりません。
Windows以外の環境で実行している場合は、最近のSolrバージョンではOutOfMemoryErrorが発生した場合にSolrプロセスを停止するオプションが始動時に含まれています。これは、OOMEの後にプログラムの動作が完全に予測できなくなるためです。何が起こるかは全く予測できませんが、インデックスの破損なども含まれます。
後のメッセージでレプリカを追加したことが分かりました。これによりより多くのスレッドが生成されます。SolrCloudには組み込みの負荷分散機能がありますが、クエリを特定のコアに送信せずに（コレクションではなく）URLにdistrib=falseを含めない限り、リクエストを受け取ったマシンでクエリが処理される保証はありません。リクエストが別のマシンに転送される場合もあり、それには追加のスレッドが必要になります。もしコレクションがシャーディングされている場合、distrib=falseを使用しないでください。そうしないと、1つのシャードのみにクエリが送られます。
以上、ご参考まで。
Shawn
どこから | 文字が出てきたのか分かりません。私が送ったメッセージには見当たりませんでした。そこにあるべきではありません。
ありがとうございます。
Shawn
アドバイスありがとうございます。それは有望な方向に見えますね。
ただし、私たちのクラスターで nproc と nofile をチェックしたところ、現在それぞれ 4096 に設定されています。理論上の1024とは異なりますね。おそらくそれを8192に引き上げてみることにしますが、初期の予想ほどの影響はないかもしれません。それでも問題が解決すると思いますか？
問題が発生するときに遭遇するスレッドの数は、nproc（1000対4096）よりもかなり少ないです。これは問題の原因が異なる可能性がある兆候だと思いますか？
Linuxで実行中のプロセスの実際の有効な制限を確認するには、以下のコマンドを使用します。ここで、NNNNNは確認したいプロセスのPIDです：
cat /proc/NNNNN/limits
他のオペレーティングシステムで利用可能なオプションについては分かりません。
4096はおそらく十分ですが、突然の負荷スパイクに対応するためにも、より高い値を許容しておくのが好みです。以前、私が勤めていた会社の大規模なインストールでSolrインスタンスをjconsoleでチェックしたとき、最高スレッド数はおおよそ1300程度でした。現在私がメールサーバー用に実行している小さなSolrインスタンスでは、現在46スレッド稼働しています。システム全体でユーザーごとの制限としてnprocとnofileを8192に設定していますが、実際に必要な以上に多くです。全体のシステムで使用されているスレッド／プロセスの数は618で、予想よりもはるかに少ないです。
ありがとうございます。
Shawn
別の原因として、OSで利用可能なメモリが不足している可能性も考えられます。
過去に類似の問題に直面したことがあり、ある程度のメモリを解放した後に問題が解消しました。
例えば、マシン／サーバーの総メモリが6 GBで、Javaプロセスが5.4 GBを割り当てており、OSには600 MBしか残っていなかった場合、同じ問題（ネイティブスレッドの作成ができない）が発生しました。Javaに割り当てるメモリを減らし、OSに十分なメモリを残したところ、問題が解決しました。
ありがとうございます。
Rajendra Gaikwad
トピックへ返信するには、ログインが必要です。