That is the problem with a jvm, it is a virtual machine. Ask 10 experts about a good jvm settings and you get 15 answers. May be a tradeoff of the flexibility of jvm's. There is always a right setting for any application running on a jvm but you just have to find it. How about a Solr Wiki page about JVM settings for Solr? The good, the bad and the ugly? With a very short describtion why to set it (or not) and what it will affect?
By the way while looking for upgrading to JDK7, the release notes say under section "known issues" about the "PorterStemmer" bug: "...The recommended workaround is to specify -XX:-UseLoopPredicate on the command line." Is this still not fixed, or won't fix? So this could be a candidate for an entry about JVM settings on the wiki page. Regards Bernd Am 19.09.2012 18:14, schrieb Rozdev29: > I have used this setting to reduce gc pauses with CMS - java 6 u23 > > XX:+ParallelRefProcEnabled > > With this setting, jvm does gc of weakrefs with multiple threads and pauses > are low. > > Please use this option only when you have multiple cores. > > For me, CMS gives better results > > Sent from my iPhone > > On Sep 19, 2012, at 8:50 AM, Walter Underwood <wun...@wunderwood.org> wrote: > >> Ooh, that is a nasty one. Is this JDK 7 only or also in 6? >> >> It looks like the "-XX:ConcGCThreads=1" option is a workaround, is that >> right? >> >> We've had some 1.6 JVMs behave in the same way that bug describes, but I >> haven't verified it is because of finalizer problems. >> >> wunder >> >> On Sep 19, 2012, at 5:43 AM, Erick Erickson wrote: >> >>> Two in one morning.... >>> >>> The JVM bug I'm familiar with is here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112034 >>> >>> FWIW, >>> Erick >>> >>> On Wed, Sep 19, 2012 at 8:20 AM, Shawn Heisey <s...@elyograg.org> wrote: >>>> On 9/18/2012 9:29 PM, Lance Norskog wrote: >>>>> >>>>> There is a known JVM garbage collection bug that causes this. It has to do >>>>> with reclaiming Weak references, I think in WeakHashMap. Concurrent >>>>> garbage >>>>> collection collides with this bug and the result is that old field cache >>>>> data is retained after closing the index. The bug is more common with more >>>>> processors doing GC simultaneously. >>>>> >>>>> The symptom is that when you run a monitor, the memory usage rises to a >>>>> peak, drops to a floor, rises again in the classic sawtooth pattern. When >>>>> the GC bug happens, the ceiling becomes the floor, and the sawtooth goes >>>>> from the new floor to a new ceiling. The two sizes are the same. So, 2G to >>>>> 5G, over and over, suddenly it is 5G to 8G, over and over. >>>>> >>>>> The bug is fixed in recent Java 7 releases. I'm sorry, but I cannot find >>>>> the bug number. >>>> >>>> >>>> I think I ran into this when I was looking at memory usage on my SolrJ >>>> indexing program. Under Java6, memory usage in jconsole (remotely via JMX) >>>> was fairly constant long-term (aside from the unavoidable sawtooth). When >>>> I >>>> ran it under Java 7u3, it would continually grow, slowly ... but if I >>>> measured it with jstat on the Linux commandline rather than remotely via >>>> jconsole under windows, memory usage was consistent over time, just like >>>> under java6 with the remote jconsole. After looking at heap dumps and >>>> scratching my head a lot, I finally concluded that I did not have a memory >>>> leak, there was a problem with remote JMX monitoring in java7. Glad to >>>> hear >>>> I was not imagining it, and that it's fixed now. >>>> >>>> Thanks, >>>> Shawn >>>> >> >> -- >> Walter Underwood >> wun...@wunderwood.org >> >> >> >
