Mailing-List: contact commits-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Thu, 01 Jan 2015 19:07:08 -0000
Message-ID: <20150101190708.82145.16203@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSolr_Wiki=5D_Update_of_=22ShawnHeisey=22_by_ShawnHeisey?=
Auto-Submitted: auto-generated

Dear Wiki user,

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

The "ShawnHeisey" page has been changed by ShawnHeisey:
https://wiki.apache.org/solr/ShawnHeisey?action=3Ddiff&rev1=3D22&rev2=3D23

Comment:
Adjusted image size and included info about the default region size.

  =

  Here's a graph of the GC times with the settings above.  The heap size fo=
r 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-regi=
on.png||width=3D600}}]]
+ [[attachment:gc-7u72-with-8m-region.png|{{attachment:gc-7u72-with-8m-regi=
on.png||width=3D1024}}]]
  =

- /!\ Some notes about the !G1HeapRegionSize parameter:  I was seeing a lar=
ge number of "humongous allocations" in the GC log, which means that they a=
re larger than 50 percent of a G1 heap region.  Those allocations were abou=
t 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 f=
ilterCache entries for an index that size are approximately 2MB.  Setting t=
he region size to 8MB ensures that those allocations are not categorized as=
 humongous.  Such objects are better handled in the young generation, but i=
f they are categorized as humoungous, they will be allocated from the old g=
eneration and more full GCs will be required.  See "Humongous Allocations" =
section on this [[http://www.infoq.com/articles/tuning-tips-G1-GC|blog entr=
y]] for more information.  Depending on the size of your indexes and the si=
ze 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 opt=
ions 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 manag=
es large allocations a lot better than Java 7 does.
+ /!\ Some notes about the !G1HeapRegionSize parameter:  I was seeing a lar=
ge number of "humongous allocations" in the GC log, which means that they a=
re larger than 50 percent of a G1 heap region.  Those allocations were abou=
t 2MB in size, and my 4GB minimum heap results in a default region size of =
2MB, which is calculated by dividing the -Xms value by 2048.  I suspect tha=
t those allocations were for filterCache entries, because the indexes on th=
at instance are each about 16 million documents, and the filterCache entrie=
s 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 catego=
rized as humoungous, they will be allocated from the old generation and mor=
e full GCs will be required.  See "Humongous Allocations" section on this [=
[http://www.infoq.com/articles/tuning-tips-G1-GC|blog entry]] for more info=
rmation.  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 cr=
eate a log you can search for "humongous" to determine if there are a lot o=
f these allocations.  I have been informed that with Java 8u40, the !G1Heap=
RegionSize parameter is not required, because Java 8 manages large allocati=
ons a lot better than Java 7 does.
  =

  =3D=3D=3D CMS (ConcurrentMarkSweep) Collector =3D=3D=3D
 =20