Interesting, I'd also been considering moving to G1. I understand that it 
works well with large (>4GiB) heap sizes compared with the default. I'll 
give it a try.

I'm not sure how to imitate production load on a test cluster -- it's a 
diverse range of data, very bursty and high average throughput. I'll 
increase GC logging on the production ES cluster to try to make the long GC 
tuning road more pleasant :)

On Tuesday, 18 November 2014 21:18:01 UTC, Norberto Meijome wrote:
>
> FWIW, we saw many long running GC events using the default GC manager - 
> changing to G1 solved most of the problems ( at the expense of slightly 
> higher CPU all the time).... After that you can take the longer road to 
> debugging memory allocation for your use case :-)
> On 18/11/2014 6:21 am, "Wilfred Hughes" <[email protected] <javascript:>> 
> wrote:
>
>> We're running elasticsearch 1.2.4 on Java 1.7.0_40, for what it's worth.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elasticsearch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elasticsearch/44213a82-7604-430c-9017-8d4398f9694d%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elasticsearch/44213a82-7604-430c-9017-8d4398f9694d%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/25a5b535-a2ed-4103-9037-853a56af7c79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to