On 11/21/2012 12:36 AM, stockii wrote:
okay. i will try out more RAM.
i am using not much caching because of "near-realt-time"-search. in this
case its better to increase xmn or only xmx and xms?
I have personally found that increasing the size of the young generation
(Eden) is beneficial to Solr, at least if you are using the parallel GC
options. I theorize that the collector for the young generation is more
efficient than the full GC, but that's just a guess. When I started
doing that, the amount of time my Solr JVM spent doing garbage
collection went way down, even though the number of garbage collections
went up.
Lately I have been increasing the Eden size by using -XX:NewRatio=1
rather than an explicit value on -Xmn. This has one advantage - if you
change the min/max heap size, the same value for NewRatio will still work.
Here are the options that I am currently using in production with Java6:
-Xms4096M
-Xmx8192M
-XX:NewRatio=1
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
Here is what I am planning for the future with Solr4 and beyond with
Java7, including an environment variable for Xmx. Due to the
experimental nature of the G1 collector, I would only trust it with the
latest Java releases, especially for Java6. The Unlock option is not
required on Java7, only Java6.
-Xms256M
-Xmx${JMEM}
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
Thanks,
Shawn
