Solr Cloudにおけるレプリカごとに登録される最大検索者数
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/nftq5mw8h8zgth07km8d33n7ddp4j7f6 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
8ノードのクラスターがあり、それぞれのノードにはPULLタイムのレプリカが1つずつ含まれています。
ここ数時間、突然1つのサーバーで高いCPU使用率と負荷が発生しています（他のサーバーの2倍）。
SolrのGrafanaダッシュボードを確認したところ、この特定のノードの「Mapped Total Capacity（Jvm Metrices->Buffer sizeセクション）」が他のサーバーの約2倍であることが判明しました（54GB対28GB）。
さらに、この特定のサーバーの「CORE（Plugin/Stats）」をチェックしたところ、このコアに2つの検索者が登録されていました。以下のようなものです。
Searcher@56aea1d7[im-search-03-08-22_shard2_replica_p19] mainsearchercore
Searcher@6f3bd5b7[im-search-03-08-22_shard2_replica_p19] main
他のサーバーの検索者数も確認しましたが、各コアには1つしか見つかりませんでした。例として：
searcherSearcher@7a7e7ba3[im-search-03-08-22_shard1_replica_p17] maincore
このコアに2つの検索者が存在することが負荷とCPU使用率の増加の原因となっている可能性はありますか？
また、1コアに1つの検索者しか存在しないというのが私の理解でしたが、なぜ2つの検索者があるのでしょうか？
もしこれが問題である場合、再発防止のためにどのような設定が可能でしょうか？
通常、複数の検索者が存在する場合、既存の検索者がクエリを処理している間に、少なくとも1つの新しい検索者が代替としてウォームアップされているためです。新しい検索者が完全にウォームアップされると、既存の検索者は、それを使用しているすべてのクエリが完了した時点でシャットダウンします。
検索者に割り当てられた28GBのヒープメモリは非常に過剰に思えます。solrconfig.xmlのキャッシュ設定とコア内の最大ドキュメント数を共有していただけますか？
ありがとうございます。
Shawn
こんにちは、Shawn
ヒープサイズではないと思います。私たちは8GBのヒープサイズしか割り当てていません。Grafanaダッシュボードでは「solr mapped total capacity」として表示されていました。ヒープサイズセクションもあり、そこで8GBに基づいたヒープ使用量を見ることができました。しかし、このサーバーのGCカウントと時間も高かったです。
おそらく、これはインデックスディレクトリのmmapディレクトリ実装に関連していると思いますが、間違っているかもしれません。
これらの2つの検索者は午前11時から存在しています。そして、毎回コミット後にさらに2つの検索者が再びオープンされています。
現在の検索者は以下の通りです。
- Searcher@479c8248[im-search-03-08-22_shard2_replica_p19] main
- Searcher@6f3bd5b7[im-search-03-08-22_shard2_replica_p19] main
キャッシュ設定も共有します。このレプリカには合計1800万件のドキュメントがあります（最大2500万件、削除されたドキュメント700万件）。
<filterCache class="solr.CaffeineCache" size="1000" initialSize="300" autowarmCount="100" />
<queryResultCache class="solr.CaffeineCache" size="30000" initialSize="1000" autowarmCount="100" />
<documentCache class="solr.CaffeineCache" size="25000" initialSize="512" autowarmCount="512" />
なるほど。MMAPスペースは実際に取られているメモリの量ではなく、アクセス可能なデータの量を示しています。OSがそのデータのどれだけを実際にメモリに載せるかを管理しています。
あなたのタイムゾーンがわからないので、かなり前の話だと仮定していますが、午前11時に見たのと同じ検索者であることに確信がありますか？ Plugins/Statsで見える各検索者のwarmupTimeはどれくらいですか？
追加メッセージを見ました。モジュールやカスタムコードを実行していますか？ 追加のjarを読み込む必要があるものはありますか？
ありがとうございます。
Shawn
Shawn,
以前は複数の検索者については気づきませんでした。多くのデバッグの後にこのことに気づきました。
そして、最初に質問を投稿したときと同じ検索者であることを確認できます。
15分前にコレクションをリロードし、今は固まっていた検索者が消えました。そのため、固まっていた検索者のウォームアップ時間をお伝えすることはできません。
しかし、リロード後に「mapped total capacity」が75GBに達しました。他のサーバーではまだ25GBのままです。
私たちはカスタムの音韻実装を使用していますが、それは何年も前から稼働しています。
Shawn,
しばらくして、mapped total capacityが100GBに達しました（おそらくいくつかのコミット後です）。Young GCのカウントが倍増し、サーバーがメモリ不足エラーをスローしました。
何か洞察はありますか？これを回避するために何を確認すればよいでしょうか？
実際にOutOfMemoryError例外を見ましたか？ 例外には、どのリソースが枯渇したかのメモが含まれます。頻繁にメモリではないことがあります。適切なリソースを追跡する必要があります。
SOLR-8803で作業している内容により、OOMEの原因が常に見えるようになります。このパッチはSolr 8.xには適用できず、9.xに適用する必要があります。新しいオプションはJava 8u92に追加されたため、Solr 8.xではユーザーが十分に新しいJavaバージョンを持っていることを保証できません。Solr 9.xではJava 11が必要なので、これを保証できます。
https://issues.apache.org/jira/browse/SOLR-8803
binディレクトリに影響を与えるパッチの部分は、バイナリダウンロードに適用して新しいOOME動作を得ることができます。
ありがとうございます。
Shawn
トピックへ返信するには、ログインが必要です。