> When the heap is out of free space that >can be recovered with minor GC, the JVM will increase the size if possible. >Once it is at max, it will do a major GC.
Thanks Walter, One more quick question about the above, so if the initial HEAP was larger (or equal to the max as you suggested earlier) will the GCs minor GCs be less frequent because the HEAP still has available space? Unfortunately the system was rebooted by a infrastructure person prior to looking at `/admin/system/info` endpoint to look at the stats. Is there another way get those statistics (there is no JVM monitoring in place from our INF team so I am starting this all from scratch right now. Nick On Thu, Oct 3, 2019 at 9:44 AM Walter Underwood <wun...@wunderwood.org> wrote: > > On Oct 3, 2019, at 9:31 AM, ndra <publicmlu...@gmail.com> wrote: > > > > I was under the impression that by allocating a smaller initial HEAP I > > could avoid having a larger GCs but if I am understanding what you all > are > > suggesting, the smaller initial HEAP is requiring more full GCs to > maintian > > a HEAP closer to 512MB. Is that correct? > > I don’t think either of those are true. When the heap is out of free space > that > can be recovered with minor GC, the JVM will increase the size if possible. > Once it is at max, it will do a major GC. > > We use these settings in solr.in.sh: > > SOLR_HEAP=8g > # Use G1 GC -- wunder 2017-01-23 > # Settings from https://wiki.apache.org/solr/ShawnHeisey > GC_TUNE=" \ > -XX:+UseG1GC \ > -XX:+ParallelRefProcEnabled \ > -XX:G1HeapRegionSize=8m \ > -XX:MaxGCPauseMillis=200 \ > -XX:+UseLargePages \ > -XX:+AggressiveOpts \ > " > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > >
