mark
--
View this message in context:
http://lucene.472066.n3.nabble.com/Fatal-full-GC-tp4158429p4159827.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hi
Thank you very much. we make the change to low down the Heap size ,we are
watching the effect of this change.we will inform you about the result.
It is really helpful.
Best Regard
2014-09-12 23:00 GMT+08:00 Walter Underwood :
> I agree about the 80Gb heap as a possible problem.
>
> A GC i
I agree about the 80Gb heap as a possible problem.
A GC is essentially a linear scan of memory. More memory means a longer scan.
We run with an 8Gb heap. I’d try that. Test it by replaying logs from
production against a test instance. You can use JMeter and the Apache access
log sampler.
https
On 9/12/2014 7:36 AM, YouPeng Yang wrote:
> We build the SolrCloud using solr4.6.0 and jdk1.7.60 ,our cluster contains
> 360G*3 data(one core with 2 replica).
> Our cluster becomes unstable which means occasionlly it comes out long
> time full gc.This is awful,the full gc take long take that the
Hi
We build the SolrCloud using solr4.6.0 and jdk1.7.60 ,our cluster contains
360G*3 data(one core with 2 replica).
Our cluster becomes unstable which means occasionlly it comes out long
time full gc.This is awful,the full gc take long take that the solrcloud
consider it as down.
Normally full
Hi
We build the SolrCloud using solr4.6.0 and jdk1.7.60 ,our cluster contains
360G*3 data(one core with 2 replica).
Our cluster becomes unstable which means occasionlly it comes out long
time full gc.This is awful,the full gc take long take that the solrcloud
consider it as down.
Normally full
