Did you get an answer? Would really be nice to have that in the next
release.
On 28.08.2017 18:31, Erick Erickson wrote:
Varun Thacker is the RM for Solr 6.6.1, I've pinged him about including it.
On Mon, Aug 28, 2017 at 8:52 AM, Walter Underwood <wun...@wunderwood.org> wrote:
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
