こんにちは、Vincenzo。

はい。最後に確認したとき、各クエリに対して ScoreDoc オブジェクトの配列が作成され、そのサイズはローカルコア/レプリカの numFound に対応しています。これは VisualVM で明確に確認できるはずです。これは SolrIndexSearcher で発生します。

よろしく、
Markus

こんにちは、Markus。

説明ありがとうございます。
もし、q=*:*&rows=0 のクエリを送信し、Solrコアに2億件のドキュメントがある場合、非常に大きな ScoreDoc オブジェクトの配列を割り当てることになるのでしょうか？

--
Vincenzo D'Amore

こちらは、ビットセットに保持されるエントリ数をバイト数から計算する一例です。

(2864256 - 12 - 12) / 24 = 119343 longオブジェクト = 22913856エントリ

これは、各クエリが2864256バイト（約2.8MB）のサイズのビットセットを生成しているクラスタの例です。この結果セットには2200万件の結果が含まれています。これは、一定のサイズを超える結果セットに対しては常に固定ビットセットになるというアルゴリズムの処理が行われています。ビットセットは、シャード内の結果セットのドキュメント数に基づいて増加します。

このプロセスは、async-profilerのようなプロファイラーを使用すると簡単に確認できます。各クエリごとにビットセットが作成される様子が見られます。最近、SOLR-16555 において、フィルターキャッシュビットセットが複数のfq句がある場合に繰り返し再作成されていたのを確認しました。SOLR-16555は、私が取り組んでいたクラスタにおいてヒープ使用量を大幅に削減しました（PRから前後のメトリクスが確認できます）。

200Mのドキュメントを持つシャードがある場合、1クエリあたりのビットセットは約20MBになると思います。

追伸： G1 GCの場合、これらの大きなビットセットのほとんどは、G1リージョンサイズのために巨大な割り当てとなります。これが問題なのかどうかはわかりませんが、さらに調査したいと思っていますが、まだベンチマークを行ったり他のアプローチを検討したりする時間がありません。

Kevin Risden

それはクエリにも依存します。

例えば、collapseクエリでは、クエリの実行中に収集されたグループヘッドのマップを保持します。結果セットが大きく、かつグループ化されるフィールドのカーディナリティが高い場合、より多くのメモリを使用することになります。

Joel Bernstein
http://joelsolr.blogspot.com/