What message do you get about the heap space. It is completely normal for Java to use all of heap before running a major GC. That is how the JVM works.
wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Feb 1, 2020, at 6:35 AM, Rajdeep Sahoo <rajdeepsahoo2...@gmail.com> wrote: > > Please reply anyone > > On Fri, 31 Jan, 2020, 11:37 PM Rajdeep Sahoo, <rajdeepsahoo2...@gmail.com> > wrote: > >> This is happening when the no of indexed document count is increasing. >> With 1 million docs it's working fine but when it's crossing 4.5 >> million it's heap space is getting full. >> >> >> On Wed, 22 Jan, 2020, 7:05 PM Michael Gibney, <mich...@michaelgibney.net> >> wrote: >> >>> Rajdeep, you say that "suddenly" heap space is getting full ... does >>> this mean that some variant of this configuration was working for you >>> at some point, or just that the failure happens quickly? >>> >>> If heap space and faceting are indeed the bottleneck, you might make >>> sure that you have docValues enabled for your facet field fieldTypes, >>> and perhaps set uninvertible=false. >>> >>> I'm not seeing where large numbers of facets initially came from in >>> this thread? But on that topic this is perhaps relevant, regarding the >>> potential utility of a facet cache: >>> https://issues.apache.org/jira/browse/SOLR-13807 >>> >>> Michael >>> >>> On Wed, Jan 22, 2020 at 7:16 AM Toke Eskildsen <t...@kb.dk> wrote: >>>> >>>> On Sun, 2020-01-19 at 21:19 -0500, Mehai, Lotfi wrote: >>>>> I had a similar issue with a large number of facets. There is no way >>>>> (At least I know) your can get an acceptable response time from >>>>> search engine with high number of facets. >>>> >>>> Just for the record then it is doable under specific circumstances >>>> (static single-shard index, only String fields, Solr 4 with patch, >>>> fixed list of facet fields): >>>> https://sbdevel.wordpress.com/2013/03/20/over-9000-facet-fields/ >>>> >>>> More usable for the current case would be to play with facet.threads >>>> and throw hardware with many CPU-cores after the problem. >>>> >>>> - Toke Eskildsen, Royal Danish Library >>>> >>>> >>> >>
