You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by Apache Wiki <wi...@apache.org> on 2015/03/27 07:10:33 UTC

[Solr Wiki] Update of "ShawnHeisey" by ShawnHeisey

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "ShawnHeisey" page has been changed by ShawnHeisey:
https://wiki.apache.org/solr/ShawnHeisey?action=diff&rev1=34&rev2=35

Comment:
Added a new section under G1 for my work-in-progress tuning experiments.

  Garbage collection for allocations that are tagged as humongous is not fully handled in the concurrent and low-pause parts of the process.  They can only be properly handled by a full garbage collection, which will always be slow.  Depending on the size of your indexes and the size of your heap, the region size may require adjustment from the 8MB that I am using above.  If you have an index with about 100 million documents in it, you'll want to use a region size of 32MB, which is the maximum possible size.  Because of this limitation of the G1 collector, we recommend always keeping a Solr index below a maxDoc value of around 100 to 120 million.
  
  Further down on this page, I have included GC logging options that will create a log you can search for "humongous" to determine if there are a lot of these allocations.  I have been informed that with Java 8u40, the !G1HeapRegionSize parameter is not required, because Java 8 manages large allocations a lot better than Java 7 does.
+ 
+ This is what I am currently trying out on my servers:
+ 
+ {{{
+ JVM_OPTS=" \
+ -XX:+UseG1GC \
+ -XX:+PerfDisableSharedMem \
+ -XX:+ParallelRefProcEnabled \
+ -XX:G1HeapRegionSize=8m \
+ -XX:MaxGCPauseMillis=250 \
+ -XX:InitiatingHeapOccupancyPercent=75 \
+ -XX:+UseLargePages \
+ -XX:+AggressiveOpts \
+ "
+ }}}
  
  === CMS (ConcurrentMarkSweep) Collector ===