That would be a really good reason for a 6.7. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog)
> On Aug 28, 2017, at 8:48 AM, Markus Jelsma <markus.jel...@openindex.io> wrote: > > It is, unfortunately, not committed for 6.7. > > > > > > -----Original message----- >> From:Markus Jelsma <markus.jel...@openindex.io> >> Sent: Monday 28th August 2017 17:46 >> To: solr-user@lucene.apache.org >> Subject: RE: Solr memory leak >> >> See https://issues.apache.org/jira/browse/SOLR-10506 >> Fixed for 7.0 >> >> Markus >> >> >> >> -----Original message----- >>> From:Hendrik Haddorp <hendrik.hadd...@gmx.net> >>> Sent: Monday 28th August 2017 17:42 >>> To: solr-user@lucene.apache.org >>> Subject: Solr memory leak >>> >>> Hi, >>> >>> we noticed that triggering collection reloads on many collections has a >>> good chance to result in an OOM-Error. To investigate that further I did >>> a simple test: >>> - Start solr with a 2GB heap and 1GB Metaspace >>> - create a trivial collection with a few documents (I used only 2 >>> fields and 100 documents) >>> - trigger a collection reload in a loop (I used SolrJ for this) >>> >>> Using Solr 6.3 the test started to fail after about 250 loops. Solr 6.6 >>> worked better but also failed after 1100 loops. >>> >>> When looking at the memory usage on the Solr dashboard it looks like the >>> space left after GC cycles gets less and less. Then Solr gets very slow, >>> as the JVM is busy with the GC. A bit later Solr gets an OOM-Error. In >>> my last run this was actually for the Metaspace. So it looks like more >>> and more heap and metaspace is being used by just constantly reloading a >>> trivial collection. >>> >>> regards, >>> Hendrik >>> >>
