ah like CMSInitiatingOccupancyFraction for CMS On Wed, Sep 18, 2019 at 8:02 AM Anthony Baker <aba...@pivotal.io> wrote:
> 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.re...@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 <aba...@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.re...@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. > >> > >> > >> > >> > >> > >> > > > >
