Hi Shawn, the problem with heap regions is, you can't get one advantage without any disadvantage.
According to your G1 example: 4GB heap with default 2MB region size = 2048 heap regions 4GB heap with G1HeapRegionSize set to 8MB = 512 heap regions You see, you only have 1/4th of heap regions left. This also means that objects which are only 1MB in size occupy 8MB on heap and therefore a whole region, which is already very low. Humongous Allocations are not genrally bad. Sure, the G1 part for humongous allocations is not that performant and takes time. But just try to limit humongous allocations and not to avoid it under all circumstances. Regards Bernd Am 27.03.2018 um 23:07 schrieb Shawn Heisey: > On 3/27/2018 12:13 AM, Bernd Fehling wrote: >> may I give you the advise to _NOT_ set XX:G1HeapRegionSize. >> That is computed during JAVA start by the engine according to heap and >> available memory. >> A wrong set size can even a huge machine with 31GB heap and 157GB RAM force >> into OOM. >> Guess how I figured that out, took me about one week to locate it. > > I have some notes on why I included that parameter on my wiki page. > > https://wiki.apache.org/solr/ShawnHeisey#G1_.28Garbage_First.29_Collector > > Basically, the filterCache entries were being marked as humongous > allocations, because each one for my indexes is over 2MB in size. > Apparently it takes a full collection to collect humongous allocations > that become garbage, at least in the versions of Java that I was > experimenting with. So without that parameter, full GCs were required, > and that will always make GC slow unless the heap size is very small. > > If Oracle has made it so that humongous allocations can be collected by > the generation-specific collectors, then that parameter may no longer be > required in newer Java versions. I do not know if this has happened. > > Thanks, > Shawn >
