fwiw,
Facets are much less heap greedy when counted for docValues enabled fields,
they should not hit UnInvertedField in this case. Try them.
On Thu, Apr 10, 2014 at 8:20 PM, Toke Eskildsen wrote:
> Shawn Heisey [s...@elyograg.org] wrote:
> >On 4/9/2014 11:53 PM, Toke Eskildsen wrote:
> >> The m
Shawn Heisey [s...@elyograg.org] wrote:
>On 4/9/2014 11:53 PM, Toke Eskildsen wrote:
>> The memory allocation for enum is both low and independent of the amount
>> of unique values in the facets. The trade-off is that is is very slow
>> for medium- to high-cardinality fields.
> This is where it is
On 4/9/2014 11:53 PM, Toke Eskildsen wrote:
>> This does not happen with the 'old' method 'facet.method=enum' - memory
>> usage is stable and solr is unbreakable with my hold-reload test.
>
> The memory allocation for enum is both low and independent of the amount
> of unique values in the facets.
On Thu, 2014-04-10 at 04:23 +0200, Damien Kamerman wrote:
> What I have found with Solr 4.6.0 to 4.7.1 is that memory usage continues
> to grow with facet queries.
It allocates (potentially significant) temporary structures, yes.
> Then I tried to determine a safe limit at which the search would
Hi All,
What I have found with Solr 4.6.0 to 4.7.1 is that memory usage continues
to grow with facet queries.
Originally I saw the issue with 40 facets over 60 collections (distributed
search). Memory usage would spike and solr would become unresponsive like
https://issues.apache.org/jira/browse/
