geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Baker <aba...@pivotal.io>
Subject Re: resource manager requirements & recommendations
Date Wed, 18 Sep 2019 15:02:28 GMT
I’m really interested to follow the ZGC engine and understand how well it works for geode.
 The -XX:SoftMaxHeapSize option in JDK 13 (just released) *might* be the key for us.

Anthony


> On Sep 16, 2019, at 1:31 AM, Alberto Bustamante Reyes <alberto.bustamante.reyes@est.tech>
wrote:
> 
> Thanks for the answer and the links Anthony, the discussion is interesting.
> 
> I think the differences between using CMS and G1 should be documented, I will to contribute
in this topic. For example, we have found these comments in a GemFire support ticket (https://community.pivotal.io/s/question/0D50e00005q9JT0CAM/please-refer-to-the-pivotal-ticket-210727):
> 
> "First, we are not completely compatible with G1GC yet in GemFire, meaning that some
features, percentages, etc., in GemFire need to be rethought out if changing from CMS to G1.
For example, if using eviction or critical thresholds, with CMS, these percentages would be
a % of "Tenured" heap size. For G1GC, they would be a % of "Total" heap size, because as you
may realize, G1GC doesn't have a max Eden space or max Tenured space."
> 
> 
> ________________________________
> De: Anthony Baker <abaker@pivotal.io>
> Enviado: miércoles, 11 de septiembre de 2019 18:58
> Para: dev@geode.apache.org <dev@geode.apache.org>
> Asunto: Re: resource manager requirements & recommendations
> 
> The challenge with designing a good approach for managing heap use in Java is that we
*can’t* know how much of the current heap use is really garbage.  That means that it can
be really easy to evict too much or too little data.
> 
> With the CMS engine there are tuning parameters like occupancy fraction that you can
set to match the eviction threshold.  This leads to a fairly predictable approach to managing
heap memory.  With G!GC, the challenge is harder since the entire heap might fill up with
garbage before any collections occur.
> 
> Despite CMS being deprecated, I think it’s currently the best choice to control heap
use in Geode.  As noted in JEP 291 [1] and subsequent discussion [2]:  "For some applications
CMS is a very good fit and might always outperform G1”.  I also think we need to do more
work in this area to make G1 perform as well as CMS.
> 
> Anthony
> 
> [1] http://openjdk.java.net/jeps/291
> [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-April/thread.html#start
> 
>> On Sep 11, 2019, at 9:14 AM, Alberto Bustamante Reyes <alberto.bustamante.reyes@est.tech>
wrote:
>> 
>> Hi all,
>> 
>> Im interested on using the resource manager with G1 garbage collector. To check if
it is possible, I have been reading documentation about heap memory management and I came
up with some questions because there are some points in the documentation where it is not
clear for me if they are describing requirements or recommendations.
>> 
>> As far as I understood, the requirements for using the Resource Manager are only
two:
>> 
>> *   set the critical heap percentage
>> *   configure your GC properly in order to work before the eviction procedure starts.
>> 
>> Am I right? There are three points in the documentation that makes me question if
I'm correct:
>> 
>> 
>> 1.  The first chapter in https://geode.apache.org/docs/guide/19/managing/heap_use/heap_management.html
states how to configure your GC for improving performance, but it only talks about CMS, there
is no info about other GCs.
>> 2.  In the steps of how to configure ResourceManager, when talking about tuning GC
parameters, it talks again only about CMS.
>> 3.  In the documentation of ResourceManager class, setCriticalHeapPercentage method,
it is stated the following:
>> 
>> Many virtual machine implementations have additional VM switches to control the behavior
of the garbage collector. We suggest that you investigate tuning the garbage collector when
using this type of eviction controller. A collector that frequently collects is needed to
keep our heap usage up to date. In particular, on the Sun HotSpot VM, the -XX:+UseConcMarkSweepGC
flag needs to be set, [...]
>> 
>> So it seems that CMS is a requirement, but I have not found in the code any limitation
about using only CMS.
>> 
>> If my previous statement about the requirements is fine, then I suppose the documentation
needs a review to distinguish between generic requirements and the CMS specific use case.
>> 
>> Other question that come to my mind is about the lack of info about G1. As CMS is
deprecated since Java 9, are there any plans to test and document G1 configuration?
>> 
>> Thanks in advance for your comments!
>> 
>> Alberto B.
>> 
>> 
>> 
>> 
>> 
>> 
> 


Mime
View raw message