Yes the hashJoin will read the entire "hashed" query into memory. The
documentation explains this.
In general the streaming joins were designed for OLAP type work loads.
Unless you have a large cluster powering streaming joins you are going to
have problems with high QPS workloads.
Joel Bernstein
I have found that it could be likely due to the hashJoin in the streaming
expression, as this will store all tuples in memory?
I have more than 12 million in the collections which I am querying, in 1
shard. The index size of the collection is 45 GB.
Physical RAM of server: 384 GB
Java Heap: 22 GB
You have not told us how many documents you have, how many shards, how big the
docs are, physical RAM, Java heap, what typical search latency is etc.
If you have tried to squeeze too many docs into a single node it might get
overloaded faster, thus sharding would help.
If you return too much con
On Sun, 2017-07-02 at 15:00 +0800, Zheng Lin Edwin Yeo wrote:
> I'm currently facing the issue whereby the Solr crashed when I have
> issued too many queries with error or those with high memory usage,
> like JSON facet or Streaming expressions.
>
> What could be the issue here?
Solr does not hav
Stack trace? Memory diagnostics from top(1)? What querys?
On July 2, 2017 3:00:16 AM EDT, Zheng Lin Edwin Yeo
wrote:
>Hi,
>
>I'm currently facing the issue whereby the Solr crashed when I have
>issued
>too many queries with error or those with high memory usage, like JSON
>facet or Streaming exp
Hi,
I'm currently facing the issue whereby the Solr crashed when I have issued
too many queries with error or those with high memory usage, like JSON
facet or Streaming expressions.
What could be the issue here?
I'm using Solr 6.5.1
Regards,
Edwin
