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. >> >> >> >> >> >> >
