lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Solr Wiki] Update of "ShawnHeisey" by ShawnHeisey
Date Thu, 01 Jan 2015 18:53:37 GMT
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:

Resized image attachment embedded with the previous update.

  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}}
+ [[attachment:gc-7u72-with-8m-region.png|{{attachment:gc-7u72-with-8m-region.png||width=600}}]]
  /!\ 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 [[|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.

View raw message