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/01/01 19:40:20 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=20&rev2=21

  -XX:+AggressiveOpts \
  "
  }}}
+ 
+ Here's a graph of the GC times with the settings above.  The heap size for this graph is -Xms4096M -Xmx6144M.  All of the GC pauses are well under a second, and the vast majority of them are under a quarter second:
+ 
+ {{attachment:gc-7u72-with-8m-region.png}}
  
  /!\ Some notes about the !G1HeapRegionSize parameter:  I was seeing a large number of "humongous allocations" in the GC log, which means that they are larger than 50 percent of a G1 heap region.  Those allocations were about 2MB in size.  I suspect that those were for filterCache entries, because the indexes on that instance are each about 16 million documents, and the filterCache entries for an index that size are approximately 2MB.  Setting the region size to 8MB ensures that those allocations are not categorized as humongous.  Such objects are better handled in the young generation, but if they are categorized as humoungous, they will be allocated from the old generation and more full GCs will be required.  See "Humongous Allocations" section on this [[http://www.infoq.com/articles/tuning-tips-G1-GC|blog entry]] for more information.  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.  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.