How to do force full garbage collection when heap usage goes beyond a certain threshold

[Thomas Schatzl]

Hi,

On 24.02.20 22:03, Bernd Eckenfels wrote:
> Hello Mohd,
> 
> Would be good if you can upload sample GC logs which show the issue. If 
> a mixed collection does not clean up your heap but a FullGC does you 
> might need to look into soft references or direct buffers.
> 
> If you have generally smallish heap one option would be to go to 
> ParallelOld GC, it is less sensitive to fragmentation.
> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* hotspot-gc-use <hotspot-gc-use-bounces at openjdk.java.net> im 
> Auftrag von mohd shaban <mohdshaban000123 at gmail.com>
> *Gesendet:* Monday, February 24, 2020 8:45:35 PM
> *An:* Leo Korinth <leo.korinth at oracle.com>; 
> hotspot-gc-use at openjdk.java.net <hotspot-gc-use at openjdk.java.net>
> *Betreff:* Re: How to do force full garbage collection when heap usage 
> goes beyond a certain threshold
> Hi Leo ,
> 
> Actually we set up alerts for heap utilisation and we are getting to 
> many alerts.
> So we have done the analysis and found more heap utilisation and once GC 
> happened it backs to normal but suppose my alert scheduler runs at 8:00 
> and at the same heap usage reach to 90 then we get the alert, But when i 
> monitor the heap usage , after 8:02 GC happened and it back to normal 
> usage means 50%.
> 
> So that why we want if heap usage reaches to 80-85% we trigger the GC so 
> that we can't get the alerts.
> 
> Please suggest how can we achieve this?

   by default, in jdk9+ targets 90% heap occupancy (100 - 
G1ReservePercent) to be the threshold at which old generation should be 
reclaimed. I.e. G1 will automatically start liveness analysis in the old 
gen so that at (roughly) 90% of heap usage it will start cleaning out 
old gen.

So unless you get full gcs (or evacuation failures, i.e. "to-space 
exhausted") this behavior is normal with default options, and could 
likely be fixed by increasing the G1ReservePercent value (default 10). 
GC logs, options used and JDK version used would help a lot to further 
diagnose the issue.

Thanks,
   Thomas