Just set Xms and Xmx the same. The server will be running for weeks, so allocate the memory and get on with it.
wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Oct 3, 2019, at 11:38 AM, ndra <publicmlu...@gmail.com> wrote: > >> I don’t think having the initial heap larger than the max heap is a legal > configuration. >> I have no idea what that would do. > > Sorry my wording was poor. I meant if, instead of my initial HEAP of 512MB, > it was closer to say 6 or 8GB or equal to my Max allowed of 10GB. > > Appreciate the info though. > > Thanks Watler > > Nick > > On Thu, Oct 3, 2019 at 10:57 AM Walter Underwood <wun...@wunderwood.org> > wrote: > >> I don’t think having the initial heap larger than the max heap is a legal >> configuration. >> I have no idea what that would do. >> >> Modern GCs have a separate area for short-lived allocations. When that >> fills up, >> a minor GC happens. As allocations survive several minor GCs, they are >> moved >> to the long-lived space, which is managed by major GCs. This is called a >> generational >> collector. >> >> In Solr, nearly all allocations are for a single request, so those are >> garbage after the >> response is sent. Most of the action will be in the new allocation >> (short-lived) space. >> Cache allocations get moved to the long-lived space. >> >> wunder >> Walter Underwood >> wun...@wunderwood.org >> http://observer.wunderwood.org/ (my blog) >> >>> On Oct 3, 2019, at 10:11 AM, ndra <publicmlu...@gmail.com> wrote: >>> >>>> 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) >>>> >>>> >> >>
